Also, begin to pass around base types instead of raw InOutType types. Ideally, only Sema needs to deal with them, but this means that a bunch of callers need to unwrap any inouts that might still be lying around before forming these types.
Multiple parts of the compiler were slicing, dicing, or just dropping these flags. Because I intend to use them for the new function type representation, I need them to be preserved all across the compiler. As a first pass, this stubs in what will eventually be structural rules as asserts and tracks down all callers of consequence to conform to the new invariants.
This is temporary.
and a CSApply bug with variadic tuple subscripts that I did not.
The SILGen bug was exposed by the source-compat test suite as part
of rdar://33341584.
In the type checker, we need to recognize when a member lookup succeeded through an IUO unwrap, and insert the implicit optional-unwrap component into the key path. In the standard library, we need to cope with the fact that IUO is still a first-class type with unique type metadata in a few places. Fix for rdar://problem/33230845.
Doing this allows us to return ErrorType in some circumstances where we
want to communicate that we don't have a usable type rather than writing
ErrorType directly into the type of the expression root, avoiding a
mutation of the expression tree in a failure case.
ground work for the syntactic bridging peephole.
- Pass source and dest formal types to the bridging routines in addition
to the dest lowered type. The dest lowered type is still necessary
in order to handle non-standard abstraction patterns for the dest type.
- Change bridging abstraction patterns to store bridged formal types
instead of the formal type.
- Improve how SIL type lowering deals with import-as-member patterns.
- Fix some AST bugs where inadequate information was being stored in
various expressions.
- Introduce the idea of a converting SGFContext and use it to regularize
the existing id-as-Any conversion peephole.
- Improve various places in SILGen to emit directly into contexts.
We neglected to set it on one path (a scalar-to-tuple conversion path currently only taken by subscript applications). Change TupleShuffleExpr's constructor to take it as an argument so this mistake is harder to make in the future. Fixes SR-5264 | rdar://problem/32860988.
AnyFunctionType::Param carries around information about decomposed
parameters now. Information about default arguments must be computed
separately with swift::computeDefaultMap.
Keep track of the protocol conformances required to form a particular
solution. At the point where we apply a solution, mark each of those
conformances as "used" so we're sure they are complete for later
phases (SILGen, SIL optimizer, IRGen). This general mechanism makes
sure we don't miss any cases in CSApply, such as the multi-case
illustrated in the new test where CSApply doesn't form any AST notes
describing the type erasure in a function conversion, so it otherwise
wouldn't see the conformance to mark it "used".
Pavel went most of the way down this path to track conformances last
month for unrelated reasons (that didn't really pan out). Resurrect
his work to track conformances, but only use them to mark as "used".
Fixes rdar://problem/32111710.
Track outcomes of `conformsToProtocol` calls in `simplifyConformanceConstraints`
to be able to validate conformances when solution is formed to avoid returning
solutions with nominal types with invalid conformances to protocols.
ConstraintSolver::coerceToRValue() missed a bunch of cases where we
should be dealing with lvalues, e.g., tuples, "try" expressions, and
so on. Extend TypeChecker::coerceToRValue() to deal with the
expression type side-tables and ConstraintSolver::coerceToRValue() to
it.
Fixes rdar://problem/32700180, a crash-on-valid.
When applying a solution to an ApplyExpr, we have to coerce the
argument to the input type of the function. This is because the
solution succeeds if the argument is convertible to the
function's input, not just if they are equal.
We were forgetting to do that for the special case of a type(of:),
which has its own semantics.
Fixes <rdar://problem/32435723> and
<https://bugs.swift.org/browse/SR-5168>.
Conditional and forced downcasts enter a constraint that almost
always succeeds; only when applying the solution do we evaluate
the feasability of the cast and determine if it always succeeds,
always fails, or conditionally succeeds. This changes how the
resulting AST is represented and can also emit diagnostics.
If the conditional cast is at this stage determined to always
succeed, we treat it as an unconditional cast, going through
ExprRewriter::coerceToType() to build the AST for the coercion.
However conditional cast constraints don't enter the same
restrictions into the solution as unconditional casts do, so
coerceToType() would fall over if casting a Swift type to a CF
type by first bridging the Swift type to Objective-C.
Get around this by checking for this case explicitly when
lowering a CoerceExpr.
It feels like there's a more fundamental issue here with how
casts are modeled in the constraint solver, but I'm not going
to try understanding that now.
Fixes <rdar://problem/32227571>.
If we fail when doing a coercion while generating an OpenExistentialExpr
when applying a solution during type checking, make sure that the opaque
value on that OpenExistentialExpr is cleared.
We do not visit these during normal AST walks because they normally
appear in the subexpression held by the OpenExistentialExpr. In this
case, however, we replace that subexpression with an ErrorExpr which
means we will not visit the opaque value at all, so certain operations,
like setting the type on the opaque value, will never happen, and we can
run into problems later by code that assumes the type is set.
It seems reasonable to just clear these out in cases like this since
they are not reachable by any normal means.
We cannot model a type variable bound to the ExtInfo of a function
type in the constraint solver, which means we have a hard time
propagating noescape-ness in some cases.
Fixes <rdar://problem/31910280> and <rdar://problem/32409133>.
Situations where there is a contextual RawRepresentable type is
used incorrectly would produce `<Type>(rawValue: )` fix-it only
in cases where neither or both sides of the expression are optional.
Let's fix that by adding a fix-it for optional to contextual raw
value type conversion.
Resolves: rdar://problem/32431736
More updates to read and write types from a side table in the constraint
solver and only write back into expressions when we've finished type
checking an expression.
We still write directly into expressions, and will continue to do so
until all of the code has been updated.
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
If a lazy var has no declared type, we have to type check the
initializer to get a type before we can build the getter.
Then, the initializer is type checked as part of the getter
again.
Use the new SkipApplyingSolution flag when type checking for
the first time. We still end up doing redundant work, but by
not applying the solution we avoid feeding invalid AST nodes
back into the constraint solver.
This fixes some bad diagnostics and crashes.
Fixes <https://bugs.swift.org/browse/SR-2616> and
<rdar://problem/28313602>.
