Otherwise, we'll hit an assertion failure (or produce the wrong message)
when a property has an addressor instead of a getter and setter.
rdar://problem/22363304
Swift SVN r31865
This includes a few changes:
- Enhance diagnoseGeneralConversionFailure to not ignore constraints that are fully solved by
CSDiags' heuristics.
- Enhance dictionary/array literals diagnostics to handle non-compliance to their literal
protocols with a specific and custom error message.
- Add specific QoI for turning accidental use of array literals in dictionary context into
the right dictionary syntax (with a fixit).
Swift SVN r31696
we process contextual constraints when producing diagnostic. Formerly,
we would aggressively drop contextual type information on the floor under
the idea that it would reduce constraints on the system and make it more
likely to be solvable. However, this also has the downside of introducing
ambiguity into the system, and some expr nodes (notably closures) cannot
usually be solved without that contextual information.
In the new model, expr diagnostics are expected to handle the fact that
contextual information may be present, and bail out without diagnosing an
error if that is the case. This gets us more information into closures,
allowing more specific return type information, e.g. in the case in
test/expr/closure/closures.swift.
This approach also produces more correct diagnostics in a bunch of other
cases as well, e.g.:
- var c = [:] // expected-error {{type '[_ : _]' does not conform to protocol 'DictionaryLiteralConvertible'}}
+ var c = [:] // expected-error {{expression type '[_ : _]' is ambiguous without more context}}
and the examples in test/stmt/foreach.swift, test/expr/cast/as_coerce.swift,
test/expr/cast/array_iteration.swift, etc.
That said, this another two steps forward, one back thing. Because we
don't handle propagating sametype constraints from results of calls to their
arguments, we regress a couple of (admittedly weird) cases. This is now
tracked by:
<rdar://problem/22333090> QoI: Propagate contextual information in a call to operands
There is also the one-off narrow case tracked by:
<rdar://problem/22333281> QoI: improve diagnostic when contextual type of closure disagrees with arguments
Swift SVN r31319
produce specific diagnostics about individual elements being incorrect instead of
complaining about the whole thing in aggregate.
This improves diagnostics immediately, but is also important to unblock future progress.
Swift SVN r31264
argument. For now we start with some of the most simple cases: single argument
calls. This dramatically improves the QoI for error messages in argument lists,
typically turning a error+note combo into a single specific error message.
Some minor improvements coming (and also generalizing this to n-ary calls), but it
is nice that all the infrastructure is starting to come together...
Swift SVN r30905
isSettable() returns true for these, but they don't have a setter.
Tread carefully around them.
Fixes <rdar://problem/21877598> and <rdar://problem/21933630>.
Swift SVN r30631
1) Teach resolveImmutableBase about SubscriptExprs that have
resolved the decl that they are referring to. This fixes case where we'd
generate an imprecise diagnostic because we weren't able to find the
result in the ResolvedOverloadSet list (which is because CSApply rewrite
it to a different expr node and the locator can't find it).
2) Change FailureDiagnosis::typeCheckIndependentSubExpression to have a
blacklist of expressions that aren't recursed into, along with rationale
for each node kind, instead of a short white list. This produces more
predictable results, e.g. producing the right diagnostic in
ClangModules/objc_parse.swift
Swift SVN r30118
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
- 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
done, the rest of the infrastructure is all common and can be simplified. This
leaves us with a quite small and maintainable subsystem for diagnosing these
kinds of problems.
include/swift/AST/DiagnosticsSema.def | 28 ++-----
lib/Sema/CSDiag.cpp | 132 ++++++++++------------------------
2 files changed, 48 insertions(+), 112 deletions(-)
Swift SVN r28957
this is neutral w.r.t. diagnostics quality, but deletes a ton
of code:
include/swift/AST/DiagnosticsSema.def | 21 ++---------
lib/Sema/CSDiag.cpp | 64 ++--------------------------------
2 files changed, 9 insertions(+), 76 deletions(-)
Swift SVN r28956
that make vardecls and subscripts immutable. This makes the indirect cases
a lot more specific ("this is a get-only property" instead of "this is
immutable") and allows us to consolidate a bunch of code:
2 files changed, 45 insertions(+), 119 deletions(-)
Swift SVN r28954
which tell you what the problem is, not just that you have one.
- Enhance diagnostics to be more specific about function calls producing
rvalues.
Swift SVN r28939
into account accesibility, assignments to self in a non-mutating
method (consistently), recursive components of an lvalue that makes it
non-settable, etc. Now we tell you what the *problem* was, instead of
just whining.
This fixes:
<rdar://problem/19370429> QoI: fixit to add "mutating" when assigning to a member of self in a struct
<rdar://problem/17632908> QoI: Modifying struct member in non-mutating function produces difficult to understand error message
in their full generality.
Swift SVN r28867
if it has already resolved a member binding of an UnresolvedDotExpr. This allows
us to give tailored diagnostics to indicate whether the destination is not an lvalue
because the property itself was immutable or when the base is immutable.
In addition to improved diagnostics, this allows us to fixit hint "let" to "var" on
property definitions, and we can even go so far as to fixit hint insert 'mutating' on
the enclosing func decl when self is the problem.
This fixes the non-subscript cases of:
<rdar://problem/17632908> QoI: Modifying struct member in non-mutating function produces difficult to understand error message
<rdar://problem/19370429> QoI: fixit to add "mutating" when assigning to a member of self in a struct
<rdar://problem/20234955> QoI: Error message for assigning to 'let' fields should say that the error is due to a 'let' binding
Subscript cases to follow.
Swift SVN r28854
We now produce tailored diagnostics for assignment operators that are passed a non-mutable LHS,
e.g.:
t.swift:14:3: error: cannot pass 'let' value 'x' to mutating binary operator '/='
x /= 19
~ ^
t.swift:13:1: note: change 'let' to 'var' to make it mutable
let x = 42
^~~
var
Swift SVN r27780
UnsafeMutablePointer<Void>, don't bind $T1 to Void. This fixes an
unintentional dependency on the order in which constraints are visited
by the solver.
Fix some resulting underconstrained expressions in the stdlib.
<rdar://problem/19835413> Reference to value from array changed
Swift SVN r25921
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
These changes make the following improvements to how we generate diagnostics for expression typecheck failure:
- Customizing a diagnostic for a specific expression kind is as easy as adding a new method to the FailureDiagnosis class,
and does not require intimate knowledge of the constraint solver’s inner workings.
- As part of this patch, I’ve introduced specialized diagnostics for call, binop, unop, subscript, assignment and inout
expressions, but we can go pretty far with this.
- This also opens up the possibility to customize diagnostics not just for the expression kind, but for the specific types
involved as well.
- For the purpose of presenting accurate type info, partially-specialized subexpressions are individually re-typechecked
free of any contextual types. This allows us to:
- Properly surface subexpression errors.
- Almost completely avoid any type variables in our diagnostics. In cases where they could not be eliminated, we now
substitute in "_".
- More accurately indicate the sources of errors.
- We do a much better job of diagnosing disjunction failures. (So no more nonsensical ‘UInt8’ error messages.)
- We now present reasonable error messages for overload resolution failures, informing the user of partially-matching
parameter lists when possible.
At the very least, these changes address the following bugs:
<rdar://problem/15863738> More information needed in type-checking error messages
<rdar://problem/16306600> QoI: passing a 'let' value as an inout results in an unfriendly diagnostic
<rdar://problem/16449805> Wrong error for struct-to-protocol downcast
<rdar://problem/16699932> improve type checker diagnostic when passing Double to function taking a Float
<rdar://problem/16707914> fatal error: Can't unwrap Optional.None…Optional.swift, line 75 running Master-Detail Swift app built from template
<rdar://problem/16785829> Inout parameter fixit
<rdar://problem/16900438> We shouldn't leak the internal type placeholder
<rdar://problem/16909379> confusing type check diagnostics
<rdar://problem/16951521> Extra arguments to functions result in an unhelpful error
<rdar://problem/16971025> Two Terrible Diagnostics
<rdar://problem/17007804> $T2 in compiler error string
<rdar://problem/17027483> Terrible diagnostic
<rdar://problem/17083239> Mysterious error using find() with Foundation types
<rdar://problem/17149771> Diagnostic for closure with no inferred return value leaks type variables
<rdar://problem/17212371> Swift poorly-worded error message when overload resolution fails on return type
<rdar://problem/17236976> QoI: Swift error for incorrectly typed parameter is confusing/misleading
<rdar://problem/17304200> Wrong error for non-self-conforming protocols
<rdar://problem/17321369> better error message for inout protocols
<rdar://problem/17539380> Swift error seems wrong
<rdar://problem/17559593> Bogus locationless "treating a forced downcast to 'NSData' as optional will never produce 'nil'" warning
<rdar://problem/17567973> 32-bit error message is really far from the mark: error: missing argument for parameter 'withFont' in call
<rdar://problem/17671058> Wrong error message: "Missing argument for parameter 'completion' in call"
<rdar://problem/17704609> Float is not convertible to UInt8
<rdar://problem/17705424> Poor error reporting for passing Doubles to NSColor: extra argument 'red' in call
<rdar://problem/17743603> Swift compiler gives misleading error message in "NSLayoutConstraint.constraintsWithVisualFormat("x", options: 123, metrics: nil, views: views)"
<rdar://problem/17784167> application of operator to generic type results in odd diagnostic
<rdar://problem/17801696> Awful diagnostic trying to construct an Int when .Int is around
<rdar://problem/17863882> cannot convert the expression's type '()' to type 'Seq'
<rdar://problem/17865869> "has different argument names" diagnostic when parameter defaulted-ness differs
<rdar://problem/17937593> Unclear error message for empty array literal without type context
<rdar://problem/17943023> QoI: compiler displays wrong error when a float is provided to a Int16 parameter in init method
<rdar://problem/17951148> Improve error messages for expressions inside if statements by pre-evaluating outside the 'if'
<rdar://problem/18057815> Unhelpful Swift error message
<rdar://problem/18077468> Incorrect argument label for insertSubview(...)
<rdar://problem/18079213> 'T1' is not identical to 'T2' lacks directionality
<rdar://problem/18086470> Confusing Swift error message: error: 'T' is not convertible to 'MirrorDisposition'
<rdar://problem/18098995> QoI: Unhelpful compiler error when leaving off an & on an inout parameter
<rdar://problem/18104379> Terrible error message
<rdar://problem/18121897> unexpected low-level error on assignment to immutable value through array writeback
<rdar://problem/18123596> unexpected error on self. capture inside class method
<rdar://problem/18152074> QoI: Improve diagnostic for type mismatch in dictionary subscripting
<rdar://problem/18242160> There could be a better error message when using [] instead of [:]
<rdar://problem/18242812> 6A1021a : Type variable leaked
<rdar://problem/18331819> Unclear error message when trying to set an element of an array constant (Swift)
<rdar://problem/18414834> Bad diagnostics example
<rdar://problem/18422468> Calculation of constant value yields unexplainable error
<rdar://problem/18427217> Misleading error message makes debugging difficult
<rdar://problem/18439742> Misleading error: "cannot invoke" mentions completely unrelated types as arguments
<rdar://problem/18535804> Wrong compiler error from swift compiler
<rdar://problem/18567914> Xcode 6.1. GM, Swift, assignment from Int64 to NSNumber. Warning shown as problem with UInt8
<rdar://problem/18784027> Negating Int? Yields Float
<rdar://problem/17691565> attempt to modify a 'let' variable with ++ results in typecheck error about @lvalue Float
<rdar://problem/17164001> "++" on let value could give a better error message
Swift SVN r23782
When the solver has attempted to produce a solution using the default
literal type tha has failed, dont' try every type that conforms to
that literal type. Instead, try the bridged class type (which deals
with the common AnyObject case) or one of two other options:
- For integer literals, try the default floating point type (Double)
- For string literals, try the standard library's AssertString (this
is a temporary hack)
This limits exponential blow-up in cases where the literal's type
cannot be determined from context. Addresses rdar://problem/18307267.
Swift SVN r22131
enforce its own little constraints. The type checker isn't using it for
anything, and it is just clutter.
This resolves <rdar://problem/16656024> Remove @assignment from operator implementations
Swift SVN r19960
eliminating the @'s from them when used on func's. This is progress towards
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
This also consolidates rejection of custom operator definitions into one
place and makes it consistent, and adds postfix "?" to the list of rejected
operators.
This also changes the demangler to demangle weak/inout/postfix and related things
without the @.
Swift SVN r19929
