This case attempts to diagnose assignment into an invalid lvalue which only had
a computable type due to a fixit that the constraint solver was assuming. In this
situation, don't diagnose the invalid lvalue at all, diagnose the required fix.
The desired ExtInfo here is not a clean derivation from either the source or destination ExtInfo anymore, so it's clearer and more maintainable to construct a new EI from whole cloth. Response to @jrose-apple's code review.
- If a @convention(block) function parameter was also marked @noescape, then during type-checking, we would accidentally propagate the convention directly onto a literal closure expr, instead of going through a function_conversion, which SILGen didn't handle. Fixes rdar://problem/23261912.
- If an Objective-C API declared a block parameter with a _Nonnull return of a bridged type, such as NSString *_Nonnull, then native-to-bridged thunking would fail to recognize this case, since we still bridge to an Optional type in the lowered ObjC interface. Fixes rdar://problem/23285766.
This avoids us using reserved identifiers as the enum case names of all
our underscored protocols like _ObjectiveCBridgeable. I used the
convention PROTOCOL_WITH_NAME to mirror how the known identifiers work.
Swift SVN r32924
This removes the partially-correct ABI check in Sema and diagnoses
unsupported conversions in SILGen instead. The new check is more
accurate and correctly diagnoses conversions of DeclRef's to
ABI-incompatible @convention(c) types.
This also fixes two cases where we used to crash but could instead
emit a trivial cast:
- Conversions between ABI-compatible (but not identical)
@convention(c) types
- Conversions of a DeclRef to an ABI-compatible (but not identical)
@convention(c) type
Fixes <rdar://problem/22470105>.
Swift SVN r32163
- Enhance the branch new argument label overload diagnostic to just
print the argument labels that are the problem, instead of printing
the types inferred at the argument context. This can lead to confusion
particularly when an argument label is missing. For example before:
error: argument labels '(Int)' do not match any available overloads
note: overloads for 'TestOverloadSets.init' exist with these partially matching parameter lists: (a: Z0), (value: Int), (value: Double)
after:
error: argument labels '(_:)' do not match any available overloads
note: overloads for 'TestOverloadSets.init' exist with these partially matching parameter lists: (a: Z0), (value: Int), (value: Double)
Second, fix <rdar://problem/22451001> QoI: incorrect diagnostic when argument to print has the wrong type
by specifically diagnosing the problem when you pass in an argument to a nullary function. Before:
error: cannot convert value of type 'Int' to expected argument type '()'
after:
error: argument passed to call that takes no arguments
print(r22451001(5))
^
Swift SVN r31795
change its implementation to take a list of TupleTypeElt for both the
from/to tuple type, but provider a convenience wrapper that takes the
from/to tuple type as TupleType's.
Swift SVN r31733
fixit hint in CSDiags instead of being a FixKind. This resolves a number of issues with
it, particularly that it didn't actually check to see if the function in question takes
a () argument or not.
This fixes:
<rdar://problem/21692808> QoI: Incorrect 'add ()' fixit with trailing closure
among other issues.
Swift SVN r31728
Have ClosureExpr::hasSingleExpressionBody() return true even after the
closure has been coerced to return Void, i.e., { E } has been rewritten
as { E; () }. This fixes some implicit-self diagnostics, and probably
others.
Revision to r31654 for 22441425.
Swift SVN r31665
Introduce a new "OpenedGeneric" locator for when openGeneric opens a generic
decl into a plethora of constraints, and use this in CSDiags to distinguish
whether a constraint refers to an Expr as a whole or an "aspect" of the constraint.
Use that information in FailureDiagnosis::diagnoseGeneralConversionFailure
to know whether (as a fallback) we can correctly re-typecheck an entire expr
to obtain a missing type. If we are talking about an aspect of the expr, then
this clearly won't work.
The upshot of this is that where we previously compiled the testcase in 22519983
to:
y.swift:31:9: error: type '(inout _) -> Bool' does not conform to protocol 'RawRepresentable'
let a = safeAssign
^
we now produce the somewhat more useful:
y.swift:31:9: error: argument for generic parameter 'T' could not be inferred
let a = safeAssign
^
y.swift:27:6: note: in call to function 'safeAssign'
func safeAssign<T: RawRepresentable>(inout lhs: T) -> Bool {
^
Swift SVN r31620
This removes the totally lame diagnostic telling the user to wrap
their function in a closure.
Some exotic Objective-C metatype to AnyObject conversions are still
missing, and there aren't any executable tests yet. Both will be
addressed soon.
Swift SVN r31527
Allow untyped placeholder to take arbitrary type, but default to Void.
Add _undefined<T>() function, which is like fatalError() but has
arbitrary return type. In playground mode, merely warn about outstanding
placeholders instead of erroring out, and transform placeholders into
calls to _undefined(). This way, code with outstanding placeholders will
only crash when it attempts to evaluate such placeholders.
<rdar://problem/21167372> transform EditorPlaceholderExpr into fatalError()
Swift SVN r31481
argument list mismatches, and diagnose them with a very specific error when
they occur in member lookups. This fixes
<rdar://problem/22356434> QoI: Missing diagnostic for invalid arguments passed to enum case constructor
where before we'd produce:
ee.swift:5:16: error: type of expression is ambiguous without more context
let list: E = .C(wrongLabel: 0)
~^~~~~~~~~~~~~~~~
now we produce:
ee.swift:1:17: error: incorrect argument label in call (have 'wrongLabel:', expected 'label:')
let list: E = .C(wrongLabel: 0)
^~~~~~~~~~~
label
I think that unresolved member exprs now get good diagnostics in all cases that they have
a contextual type, but of course there are lots more cases where we're not getting a
contextual type.
Swift SVN r31402
We need to be able to introduce and eliminate existentials inside
reabstraction thunks, so make this logic independent of RValue
and Expr emission.
NFC for now.
Swift SVN r31375
conversions to and from UnresolvedType. This will allow UnresolvedType to be
used more aggressively and predictably by CSDiags. This is NFC, but used in
the next patch.
Swift SVN r31318
ConstraintSystem::applySolution into its own helper function to reduce
indentation and make ConstraintSystem::applySolution much more simple
and obvious. NFC.
Swift SVN r31290
allowing these failures to hook into other diagnostic goodies (e.g. the
"did you mean to use '!' or '?'?" cases showing in the testsuite). That said,
by itself this doesn't have a huge impact, but avoids regressions with other
pending changes.
Swift SVN r31289
node, abandoning the old node. This cuts of places where we'd end up retypechecking
the original expr and getting things like Builtin.Int2048 into the diagnostic.
This is NFC, because there is some crufty stuff avoiding this sitation in CSDiags that
needs to be removed for other reasons, this simply unblocks that.
I have a more aggressive approach in mind to actually fix how we model literals, but
that isn't on my short-term todo list.
Swift SVN r31270
This is a step towards partially-applying methods that return Self
on existentials.
- We model opening of both existential values and metatypes with
OpenExistentialExpr, but erasure had two forms, ErasureExpr and
MetatypeErasureExpr. Combine them into one, since both Sema and
SILGen have similar code paths for each.
- If the source type of an ErasureExpr is a closed existential,
have Sema emit an OpenExistentialExpr, and remove SILGen's
openExistentialForErasure() path, which mostly duplicates
openExistentialImpl().
- There was one difference between openExistentialForErasure() and
openExistentialImpl(). The former would emit the opaque value in
+0 context, and the latter in a +1 with initialization. The
previous patch ensures that visitOpaqueValueExpr() generates
equivalent code in both cases.
Swift SVN r31261
<rdar://problem/18397777> QoI: special case comparisons with nil
<rdar://problem/18042123> QoI: Fixit for "if !optional" should suggest "if optional == nil"
Swift SVN r31204
It's not /really/ an infix operator, but it behaves like a very low
precedence prefix operator. On the other hand, 'try' and 'try!' can
freely move in and out of all the operations we add in fix-its, so
don't bother.
rdar://problem/22259867
Swift SVN r31200
This allows us to remove the workaround generic overloads for "print" without sacrificing good diagnostics for its unavailable overloads. (rdar://problem/21499048, rdar://problem/21582758, rdar://problem/22126141)
Swift SVN r31169
the regressions that r31105 introduced in the validation tests, as well as fixing a number
of other validation tests as well.
Introduce a new UnresolvedType to the type system, and have CSDiags start to use it
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31130
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31105
no type set on them. This is the minimal fix to address the regressions
on two validation tests, but another approach (not involving null types)
seems like it would be a good idea to investigate on mainline.
Swift SVN r31099
