In most places where we were checking "is<ErrorType>()", we now mean
"any error occurred". The few exceptions are in associated type
inference, code completion, and expression diagnostics, where we might
still work with partial errors.
Type::subst()'s "IgnoreMissing" option was fairly unprincipled, dropping
unsubstituted types into the resulting AST without any indication
whatsoever that anything went wrong. Replace this notion with a new
form of ErrorType that explicitly tracks which substituted type caused
the problem. It's still an ErrorType, but it prints like the
substituted type (which is important for code completion) and allows
us to step back to the substituted type if needed (which is used by
associated type inference). Then, allow Type::subst(), when the new
UseErrorTypes flag is passed, to form partially-substituted types that
contain errors, which both code completion and associated type
inference relied on.
Over time, I hope we can use error-types-with-original-types more
often to eliminate "<<error type>>" from diagnostics and teach
Type::subst() never to return a "null" type. Clients can check
"hasError()" to deal with failure cases rather than checking null.
This fixes a usability regression with the removal of @noreturn
in Swift 3. Previously, it was legal to write this:
let callback: () -> Int = { fatalError() }
Now that the special @noreturn attribute has been replaced with
a Never type, the above fails to typecheck, because the expression
now has type 'Never', and we expect a value of type 'Int'.
Getting around this behavior requires ugly workarounds to force the
parser to treat the body as a statement rather than an expression;
for example,
let callback: () -> Int = { _ = (); fatalError() }
This patch generalized single-expression closures to allow
the 'Never to T' conversion. Note that this is rather narrow
in scope -- it only applies to closure *literals*, single-expression
ones at that, not arbitrary function *values*.
In fact, it is not really a conversion at all, but more of a
desugaring rule for single-expression closures. They can now be
summarized as follows:
- If the closure literal has contextual return type T and
the expression has Never type, the closure desugars as
{ _ = <expr> }, with no ReturnStmt.
- If the closure literal has contextual return type T for some
non-void type T, the closure desugars as { return <expr> };
the expression type must be convertible to T.
- If the closure literal has contextual return type Void, and
the expression has some non-Void type T, the closure
desugars as { _ = <expr>; return () }.
Fixes <rdar://problem/28269358> and <https://bugs.swift.org/browse/SR-2661>.
Long term, we want to refactor the AST to reflect the current
programming model in Swift. This would include refactoring
FunctionType to take a list of ParameterTypeElt, or something with a
better name, that can contain both the type and flags/bits that are
only specific to types in parameter position, such as @autoclosure and
@escaping. At the same time, noescape-by-default has severely hurt our
ability to print types without significant context, as we either have
to choose to too aggressively print @escaping or not print it in every
situation it occurs, or both.
As a gentle step towards the final solution, without uprooting our
overall AST structure, and as a way towards fixing the @escaping
printing ails, put these bits on the TupleTypeElt and ParenType, which
will serve as a model for what ParameterTypeElt will be like in the
future. Re-use these flags on CallArgParam, to leverage shared
knowledge in the type system. It is a little painful to tack onto
these types, but it's minor and will be overhauled soon, which will
eventually result in size savings and less complexity overall.
This includes all the constraint system adjustments to make these
types work and influence type equality and overload resolution as
desired. They are encoded in the module format. Additional tests
added.
Now that TupleTypeElts are simpler in Swift 3 (though they're about to
become more complicated for other reasons), most of the cases where we
are explicitly constructing ones are really just plain copies or can
otherwise use existing helper functions.
NFC
We were asserting in ExprRewriter::visitCoerceExpr() that the conversion
we attempt is successfully. However, we have known cases where we will
emit a diagnostic and fail attempting to convert, so we should really
just bail out at this point rather than asserting.
Resovles the last part of rdar://problem/28207648.
These will be more useful once substitutions in protocol conformances
are moved to use interface types.
At first, these are only going to be used by the SIL optimizer.
When we are able to type check an expression this assert is fine,
although of little value. In the context of failed type checks, though,
it can be actively harmful.
The issue is that we can attempt to solve smaller parts of the
constraint system and assign contextual types (e.g. for the arguments of
a function) despite not being able to drill into members.
Some of the diagnostics we emit in these cases are not terribly useful,
and I've opened rdar://problem/27982012 with one example.
Resolves:
rdar://problem/25812474
rdar://problem/26589865
rdar://problem/27974638
Note that there was some non-obvious dead code here:
- We already drop conformance requirements on dependent types that
are the subject of same-type constraints, so we no longer have to
skip dependent types that are mapped to concrete types explicitly.
In fact, if this were not the case, other code that iterates over
the requirements of a GenericSignature would be wrong. The original
hack was added in 2014, I guess we fixed the ArchetypeBuilder
since then.
- We never end up here where the original type to substitute is a
recursive archetype. Recursive archetypes are not really a thing
that is implemented properly, and even in the compiler_crashers
collection this wasn't triggered.
- With the above two changes, the mapTypeIntoContext() call is not
necessary at all, which is nice because this is somewhat inefficient;
mapTypeIntoContext() walks all outer generic parameter lists to
find the archetype for the given dependent type.
This eliminates a pile of now-dead code in:
* The type checker, where we no longer have special cases for bridging conversions
* The expression ASTs, where we no longer need to distinguish bridging collection up/down casts
* SILGen, which no longer uses
Still to come is the removal of the
_(set|dictionary)Bridge(From|To)ObjectiveC(Conditional)? entrypoints
from the standard library. They're still used by some tests.
Simplify e.g., ASTContext::getBridgedToObjC(), which no longer needs
the optional return.
Eliminate the now-unused constraint kind for checking bridging to
Objective-C.
This commit built upon the work of Pull Request 3895. Apart from the
work to make the following work
```swift
let f: (Int, Int) -> Void = { x in } // this is now an error
```
This patch also implement the part 2 mentioned in the #3895
```swift
let g: ((Int, Int)) -> Void = { y in } // y should have type (Int, Int)
```
The problem here is that we would just emit 'invalid pattern'
instead of digging deeper, which meant that the fix-it for
qualified enum element access wasn't getting inserted for
more complex patterns, such as 'case X(let x)'.
Unfortunately, in the matching_patterns.swift test, we emit
too many diagnostics that are not really useful to figuring
out the problem, and the old 'invalid pattern' made more
sense. I'll work on some CSDiag tweaks to address this --
I think it makes more sense to dig there than just emit a
general 'invalid pattern' diagnostic anyway.
Fixes <rdar://problem/27684266>.
The id-as-Any work regressed cases where Swift code could specify
heterogeneous collection literals, e.g.,
var states: [String: Any] = [
"California": [
"population": 37_000_000,
"cities": ["Los Angeles", "San Diego", "San Jose"],
],
"Oregon": [
"population": 4_000_000,
"cities": ["Portland", "Salem", "Eugene"],
]
]
Prior to this, the code worked (when Foundation was imported) because
we'd end up with literals of type [NSObject : AnyObject].
The new defaulting rule says that the element type of an array literal
and the key/value types of a dictionary literal can be defaulted if no
stronger type can be inferred. The default type is:
Any, for the element type of an array literal or the value type of a
dictionary literal, or
AnyHashable, for the key type of a dictionary literal.
The latter is intended to compose with implicit conversions to
AnyHashable, so the most-general inferred dictionary type is
[AnyHashable : Any] and will work for any plausible dictionary
literal.
To prevent this inference from diluting types too greatly, we don't
allow this inference in "top-level" expressions, e.g.,
let d = ["a" : 1, "b" : "two"]
will produce an error because it's a heterogeneous dictionary literal
at the top level. One should annotate this with, e.g.,
let d = ["a" : 1, "b" : "two"] as [String : Any]
However, we do permit heterogeneous collections in nested positions,
to support cases like the original motivating example.
Fixes rdar://problem/27661580.
Implements part of SE-0110. Single argument in closures will not be accepted if
there exists explicit type with a number of arguments that's not 1.
```swift
let f: (Int, Int) -> Void = { x in } // this is now an error
```
Note there's a second part of SE-0110 which could be considered additive,
which says one must add an extra pair of parens to specify a single arugment
type that is a tuple:
```swift
let g ((Int, Int)) -> Void = { y in } // y should have type (Int, Int)
```
This patch does not implement that part.
The isExplicitlyEscaping bit, though useful for printing,
unfortunately puts us in a position where we have different bit
patterns for the same type, and thus lose much of our type equivalence
checking for overriding, protocol conformance, etc., even if we were
to take subtyping into account. We need to drop it, relying on the
existing noescape bit alone to determine the type's semantics (at
least, as long as we continue to encode this information in the type
system).
This is a partial fix; we will now be excessively printing @escaping,
but the subsequent commits will correct this. For printing, we will
instead need to be more context-aware.
This helps when we end up re-typechecking an expression, which we seem
to be doing with 'lazy'. Specifically, it was causing type inference
for lazy variables to fail, but the same issue would have come up in
other contexts as well. Note that we also set function reference kinds
of DeclRefExprs and related in the process.
Extend the handling of function reference kinds to member references
(e.g., x.f), and therefore the logic for stripping argument labels. We
appear to be stripping argument labels from all of the places where it
is required.
The constraint system tracks the type accurately and may (in the
future) make adjustments to it; use that type directly rather than
recomputing something that might be different.
String literal expressions, as well as the magic literals #file and
tuple value that is then fed into one or two call expressions. For
string literals, that tuple value was implicitly splatted, breaking
AST invariants.
Instead, keep string literals and these magic literals that produce a
string as a single expression node, but store the declarations that
will be used to transform the raw literal into the complete
literal. SILGen will form the appropriate calls. This representation
is far simpler---the AST no longer has a bunch of implicit nodes---and
doesn't break AST invariants.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
Factor out the trailing storage of call arguments, since we'll need it
for a few different kinds of expression nodes. Use it for both
CallExpr (which already had this storage, albeit with a specialized
implementation) and now SubscriptExpr.
Yet another step on the way to SE-0111, capture the argument labels
(and their locations) directly in CallExpr, rather than depending on
them being part of the tuple argument.
When we are type-checking calls, subscripts, or other call-like
expressions, use the argument labels provided by the various
expression nodes rather than those encoded in the tuple type. This
means that argument label matching now matches the callee
declaration's argument labels against the argument labels, without
relying on encoding the argument labels within types in the AST.
This refactor is a stepping stone torward SE-0111.
Introduce several new factory methods to create CallExprs, and hide
the constructor. The primary reason for this refactor is to start
moving clients over to the factory method that takes the call
arguments separately from the argument labels. Internally, it
repackages those arguments into a TupleExpr or ParenExpr (as
appropriate) so the result ASTs are the same. However, this will make
it easier for us to tease out the arguments themselves in the
implementation of SE-0111.
If something isn't a class or bridgeable by value or error bridging, we can still fall back to universal bridging by the runtime. Make this available for manual use by an explicit `as AnyObject` cast.
This is needed for declaration-based resolution subscript expressions,
which is the basis for implementing default arguments in subscripts as
well as declaration-based argument labels.
