Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
None of the restrictions like existential conversion or optional
promotion would actually match, so there is no point in trying them
just to add more unrelated fixes.
Resolves: rdar://100369066
Most of the diagnostics for extra/missing/mislabeled arguments refer
to argument to a "call". Some (but not call) would substitute in
"subscript". None would refer to an argument to a macro expansion
properly.
Rework all of these to refer to the argument in a call, subscript, or
macro expansion as appropriate. Fix up lots of tests that now say
"subscript" instead, and add tests for macro expansions.
When `&` is misplaced it creates r-value -> l-value mismatch
in the code which is just a consequence and shouldn't be diagnosed.
Resolves: rdar://96631324
Unwrap `InOutExpr` from all parens until the outermost paren or a tuple
to correctly diagnose calls like `foo(((&bar)))` or `foo(x: (&bar))`,
and suggest a fix-it with moves `&` outside parens.
Resolves: rdar://problem/71356981
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
The amp_prefix token is currently tolerated in any unary expression
context and then diagnosed later by Sema. This patch changes parsing to
only accept tok::amp_prefix in its allowed position: parameter lists.
This also fixes two "compiler crasher" tests.
If we're willing to tolerate less specific diagnostics, then we can
remove more instances of TVO_CanBindToInOut. After this change, there is
only one client of TVO_CanBindToInOut.
Also remove mention of the word “contextual” type from the diagnostic
that rewrites array literals into dictionary literals and scale back
the scope of the diagnostic. This method was catching and
mis-diagnosing too many errors that could better be handled by invalid
conversion diagnostics.
CSGen can see an AssignExpr where the destination has an
unresolved type, even in a case where no diagnostic has been
emitted yet.
It is then wrong to return an empty type from here, because
this stops us from attempting to solve the expression, which
results in no diagnostic being emitted in the end.
The test case I added produces a decent diagnostic now,
but the original one in the radar now just says 'ambiguous
without more context'. Still, better than crashing.
Fixes <rdar://problem/30685195>.
Update for SE-0107: UnsafeRawPointer
This adds a "mutating" initialize to UnsafePointer to make
Immutable -> Mutable conversions explicit.
These are quick fixes to stdlib, overlays, and test cases that are necessary
in order to remove arbitrary UnsafePointer conversions.
Many cases can be expressed better up by reworking the surrounding
code, but we first need a working starting point.
* Migrate from `UnsafePointer<Void>` to `UnsafeRawPointer`.
As proposed in SE-0107: UnsafeRawPointer.
`void*` imports as `UnsafeMutableRawPointer`.
`const void*` imports as `UnsafeRawPointer`.
Occurrences of `UnsafePointer<Void>` are replaced with UnsafeRawPointer.
* Migrate overlays from UnsafePointer<Void> to UnsafeRawPointer.
This requires explicit memory binding in several places,
particularly in NSData and CoreAudio.
* Fix a bunch of test cases for Void->Raw migration.
* qsort takes IUO values
* Bridge `Unsafe[Mutable]RawPointer as `void [const] *`.
* Parse #dsohandle as UnsafeMutableRawPointer
* Update a bunch of test cases for Void->Raw migration.
* Trivial fix for the SceneKit test case.
* Add an UnsafeRawPointer self initializer.
This is unfortunately necessary for assignment between types imported from C.
* Tiny simplification of the initializer.
* Migrate from `UnsafePointer<Void>` to `UnsafeRawPointer`.
As proposed in SE-0107: UnsafeRawPointer.
`void*` imports as `UnsafeMutableRawPointer`.
`const void*` imports as `UnsafeRawPointer`.
Occurrences of `UnsafePointer<Void>` are replaced with UnsafeRawPointer.
* Migrate overlays from UnsafePointer<Void> to UnsafeRawPointer.
This requires explicit memory binding in several places,
particularly in NSData and CoreAudio.
* Fix a bunch of test cases for Void->Raw migration.
* qsort takes IUO values
* Bridge `Unsafe[Mutable]RawPointer as `void [const] *`.
* Parse #dsohandle as UnsafeMutableRawPointer
* Update a bunch of test cases for Void->Raw migration.
* Trivial fix for the SceneKit test case.
* Add an UnsafeRawPointer self initializer.
This is unfortunately necessary for assignment between types imported from C.
* Tiny simplification of the initializer.
wraps up SE-0004 and SE-0029.
I consider the diagnostic changes in Constraints/lvalues.swift to be
indicative of a QoI regression, but I'll deal with that separately.
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
