- Remove all uses of CleanupIllFormedExpressionRAII from this file, which are now
unnecessary since this is handled at a higher level.
- Stop splatting ErrorType in the diagnostics stuff. This was formerly needed to
indicate that a diagnostic is emitted, but is now handled other ways. Removing
this enables the type checker to produce other follow on warnings in some cases
(e.g. var should be marked let).
- Remove an arbitrary limitation on unop and binops that didn't print an overload
candidate set with one entry, leading to better consistency in diagnostics, now
that all the pieces are in place to make this not be super annoying.
Swift SVN r30084
RebindSelfInConstructorExpr, which gets issues related to
self.init and super.init onto the CallExpr best path, instead
of in the generic overload constraint failure morass.
Swift SVN r30067
argument list for a CallExpr instead of matching a gang of typevartypes against them.
This allows us to produce better matches in some cases.
Swift SVN r30065
disjunction candidate set for a constraint that fails to match, not just
a single Bind within it. This eliminates the arbitrary nature of picking
one match, allowing us to diagnose the entire candidate set.
This exposed that we were trying to do argument matching of 'self' against
the partially curried arguments. Adjust the hack we have for that a bit to
make things work, but there are bigger problems for argument matching that
will need to be addressed.
Swift SVN r30064
facilities used by operators etc. This required a bunch of changes to make
the diagnostics changes strictly an improvement:
- Teach the new path about calls to TypeExprs.
- Teach evaluateCloseness some simple things about varargs.
- Make the generic diagnosis logic produce a better error when there is
exactly one match.
Overall, the resultant diagnostics are a step forward: we now produce candidate
set notes more uniformly, and the messages about some existing ones are
more specific. This is just another stepping stone towards progress though.
Swift SVN r30057
Now for:
let req = NSURLRequest(URL: NSURL(string: "<some url>")!)?
instead of producing:
test.swift:2:58: error: could not find an overload for 'init' that accepts the supplied
we produce the correct diagnostic, with a fixit:
error: cannot use optional chaining on non-optional value of type 'NSURLRequest'
let req = NSURLRequest(URL: NSURL(string: "<some url>")!)?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
This also consolidates some existing diagnostics to improve their wording.
Swift SVN r30049
satisfying the request of <rdar://problem/20409366> Diagnostics for init calls should print the class name
I'm keeping that radar open though, because the case in it should get better still.
Swift SVN r30029
Completely revamp getTypeOfIndependentSubExpression, to return the subexpression produced by
type checking instead of just a type. This is important for cases when type checking changes
the root of the AST (e.g. resolving an unresolved_dot_expr) and allows us to eliminate grungy
and unsafe recovery code that was in place to work around this. The last point makes the
examples in Constraints/lvalues.swift better (giving a somewhat generic error instead of an
specific-but-incorrect error that 'z' is immutable),
but more importantly, it fixes a class of crashers like:
<rdar://problem/21369926> Malformed Swift Enums crash playground service
where we'd end up with a LiteralExpr typed as Int instead of a Builtin integer type of some sort.
Swift SVN r30028
... by reimplementing the DiscardAssignmentExpr checker in MiscDiagnostics
instead of being in CSApply (which gets run on partial expression ASTs).
Also, when type checking and salvaging an expression fails, do not generate
structural diagnostics in addition to the type checker diagnostics, they are
just noise.
Swift SVN r29937
- Fix a diagnostic to not include redundant ''s around a type name.
- Rework CleanupIllFormedExpression to be simpler and to not
unconditionally destroy data when it doesn't. This makes a code
completion test a bit more precise.
- Completely revamp getTypeOfIndependentSubExpression, to return the
subexpression produced by type checking instead of just a type. This
is important for cases when type checking changes the root of the AST
(e.g. resolving an unresolved_dot_expr) and allows us to eliminate
grungy and unsafe recovery code that was in place to work around this.
The last point makes the examples in Constraints/lvalues.swift better (giving
a somewhat generic error instead of an specific-but-incorrect error that 'z'
is immutable), but more importantly, it fixes a class of crashers like
<rdar://problem/21369926> Malformed Swift Enums crash playground service
where we'd end up with a LiteralExpr typed as Int instead of a Builtin integer
type of some sort.
Swift SVN r29932
and change it to get the source before the destination. This is the right thing to
do and also conveniently works around a bogus:
'_' can only appear in a pattern or on the left side of an assignment
diagnostic.
This needs to be fixed in a more systematic way to cover other cases, but this change
is the right thing to do independently of that.
Swift SVN r29929
when we're diagnosing a value member constraint but have resolved the base, then the
member must not exist. Diagnose this with a specific message.
Swift SVN r29908
value member constraints do.
This fixes:
<rdar://problem/21662365> QoI: diagnostic for for-each over an optional sequence isn't great
before we'd produce:
t.swift:3:10: error: '[Int]?' does not have a member named 'Generator'
for x in array {
^
now we produce:
t.swift:3:10: error: value of optional type '[Int]?' not unwrapped; did you mean to use '!' or '?'?
for x in array {
^
Swift SVN r29902
- Remove a weird special case for literals from TypeChecker::typeCheckCondition.
- Enhance FailureDiagnosis::getTypeOfIndependentSubExpression to know about situations
where recursive type checks fail (in some nested situation) but still produce a type
for the top level of the expr tree.
- Remove dead code from CSApply now that you can't branch on Builtin.Int1.
The first & second combine to slightly improve one case I've been looking at in
test/expr/expressions.swift.
Swift SVN r29860
expressions. Broadening from callexpr to apply expr (picking up operators) improves
several diagnostics in the testsuite, and is important to avoid regressions from an
upcoming patch.
Swift SVN r29821
- Enhance subscript diagnostics to chase into the constraint system to find
overload candidates that failed to match so we can rank and diagnose
subscript ambiguities using the same mechanics we have for operators.
- Implement a copy of suggestPotentialOverloads based on the new mechanics
for overload set resolution. This allows us to diagnose these in a more
detailed way, but for now we're keeping it as similar to the old system as
possible. The old version to be removed once the last client moves off it.
- Add a bunch of testcases to decl/subscript/subscripting.swift where we are
doing unfortunate things still.
Swift SVN r29810
ApplyExpr involved in the overload failure, wire it up to some of the
mechanics we have for more specific situations, including diagnosing
the last (known to me) mutation issues that weren't being specifically
diagnosed, as well as printing the candidate set in these cases.
Swift SVN r29797
This teaches overload constraint diagnosis to look at the resolved anchor
expression that fails (instead of assuming that it is the expr itself) and
walks up the AST to find the applyexpr in question. This allows us to give
much more specific diagnostics for overload resolution failures, and to give
much more specific location information.
Where before my recent patches we used to produce:
t.swift:2:3: error: cannot invoke 'assert' with an argument list of type '(Bool, String)'
assert(a != nil, "ASSERT COMPILATION ERROR")
^
t.swift:2:9: note: expected an argument list of type '(@autoclosure () -> Bool, @autoclosure () -> String, file: StaticString, line: UWord)'
assert(a != nil, "ASSERT COMPILATION ERROR")
^
with this and the other recent patches, we now produce:
t.swift:2:12: error: cannot invoke '!=' with an argument list of type '(Int, nil)'
assert(a != nil, "ASSERT COMPILATION ERROR")
~~^~~~~~
Swift SVN r29792
its diagnostics in post-order. Notably, this picks up support for if-expr, which
gives up much better diagnostics in ternary operators. For example, rdar://17224804
used to produce:
error: could not find an overload for '<=' that accepts the supplied arguments
var monthString = (monthNumber <= 9) ? ("0" + monthNumber) : String(monthNumber)
~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
now we produce:
error: binary operator '+' cannot be applied to operands of type 'String' and 'Int'
var monthString = (monthNumber <= 9) ? ("0" + monthNumber) : String(monthNumber)
~~~ ^ ~~~~~~~~~~~
note: overloads for '+' exist with these partially matching parameter lists: (Int, Int), (String, String), (UnsafeMutablePointer<Memory>, Int), (UnsafePointer<Memory>, Int)
var monthString = (monthNumber <= 9) ? ("0" + monthNumber) : String(monthNumber)
^
which is the correct diagnostic. While I'm at it, improve the location info for this
binary operator diagnostic to point to the right spot (the operator) and highlight
the LHS/RHS of the operator.
Swift SVN r29774
path associated with them, and to dig the expression the constraint refers to out
of the locator. Also teach simplifyLocator how to simplify closureexpr results out.
This eliminates a class of completely bogus diagnostics where the types reported
don't make any sense, resolving a class of radars like 19821875, where we now
produce excellent diagnostics.
That said, we still pick constraints to report that are unfortunate in some cases,
such as the example in expr/closure/closures.swift.
Swift SVN r29757
It looks like we were checking in the wrong place, as a result we didn't
catch stuff like
class G<T : AnyObject> {}
_ = G<P>()
This would crash later in IRGen.
Make the conformsToProtocol() check do the right thing, and remove some
other miscellaneous diagnostics in the process. Also, make the
"type 'T' does not conform to protocol 'P'" diagnostic a bit more
detailed.
Unfortunately in a few instances we lose a more descriptive diagnostic to
a general 'cannot invoke 'foo' with argument list of type 'T'' error. The
argument matching diagnostics need to be addressed anyway though.
Fixes <rdar://problem/20311619>.
Swift SVN r29737
- Fix TypeCheckExpr.cpp to be more careful when propagating sugar from an
argument to the result of the function. We don't want to propagate parens,
because they show up in diagnostics later.
- Restructure FailureDiagnosis::diagnoseFailure() to strictly process the tree
in depth first order. Before it would only do this if contextual typing was
unavailable, leading to unpredictable inconsistencies between diagnostics.
- Always perform diagnoseContextualConversionError early, as part of the thing
that calls the visitor, instead of in each visit method. This may change in
the future, but is a simplification for now.
- Make the operator processing code handle the "candidate is an exact match"
case by emitting a diagnostic indicating that the result type of the operator
must not match expectations, instead of emitting the silly things like
"binary operator '&' cannot be applied to two Int operands" which is obviously
false.
These changes lead to minor improvements across the testsuite, and should make the
diagnostics more predictable for more complex real-world ones, but I haven't gone
through the radars yet.
Major missing pieces:
- CallExpr isn't using the same logic that the operators are.
- When you have a near match (only one argument mismatches) we should specifically
complain about that argument, instead of spewing an entire argument list.
- The noescape function attr diagnostic is being emitted twice now.
Swift SVN r29733
- When diagnosing an error passing a noescape function to an escapeing function pointer,
return 'true' to avoid follow-on bogus error messages and notes being produced.
- Start classifying the closeness of overload matches, to allow future diagnostics to be
improved.
Note that the second regresses the testcase in test/Constraints/generics.swift because the
decomposeArgumentType function doesn't know to look through the archetype for the protocol
present on the operator, and thus thinks the function only takes one argument. Advice on
how to best detect this situation is appreciated.
Swift SVN r29731
win from this other than simplification. Some minor wins are that we handle varargs
better and don't get extraneous ()'s in types in some cases.
Swift SVN r29729
them with diagnoseGeneralFailure() which would miss out on the common cases
where the subexpr of the ParenExpr is the issue.
For example, before we would produce:
t.swift:8:8: error: could not find an overload for '&' that accepts the supplied arguments
if !(x & 4.0) {}
~~~^~~~~~
now we produce:
t.swift:8:6: error: binary operator '&' cannot be applied to operands of type 'Int' and 'Double'
if !(x & 4.0) {}
^
t.swift:8:6: note: overloads for '&' exist with these partially matching parameter lists: (Int, Int)
if !(x & 4.0) {}
^
also, remove some special handling for lvalues and inout from overload
diagnostics, which can't matter anymore.
Swift SVN r29661
by propagating the 'is return expr' bit more carefully in sequence folding, and by
adding another path for handling the return diagnostics better.
This probably improves a number of cases where we complain about "this argument list
is invalid" when the call is in the context of a return.
Swift SVN r29565
lvalues when compiling list of partial-match overloads in diagnosis.
(This is a reapplication of commits r29462 and r29469.)
Also, fix the following tests:
stdlib/FixedPointDiagnostics.swift.gyb
stdlib/NumericDiagnostics.swift.gyb
<rdar://problem/17875634> can't append to array of tuples
Swift SVN r29493
This reverts commit r29462 because it looks like it breaks the following
tests:
Swift :: stdlib/FixedPointDiagnostics.swift.gyb
Swift :: stdlib/NumericDiagnostics.swift.gyb
Swift SVN r29484
getTypeOfIndependentSubExpression() might replace some values in the
given expression with OpaqueValueExprs, but if the type checker
decided to insert the corresponding OpenExistentialExpr at the top
level, the AST would now be in an inconsistent state, since
getTypeOfIndependentSubExpression() does not return a new expression
to the caller.
Ideally we would separate out type checking from expression rewriting
so that the latter is only performed when we know the expression
type checks, but that is a bigger project. For now, erase open
existentials after re-typechecking a sub-expression.
Fixes <rdar://problem/20598568>.
Swift SVN r29400
