We can wind up in a situation where the base of a keypath
application is concrete but is being applied to a keypath
with an existential source type. Coerce the base to the
intended type if necessary when building the final subscript
expression.
Resolves SR-5878.
- Remove dead `if !genericEnv` checks
- Do conformance checks for subscript indexes `InExpression`
- Use `GenericEnvironment::mapTypeOutOfContext` static method instead of null checking everywhere
The base mutability of storage is part of the signature, so be sure
to compute that during validation. Also, serialize it as part of
the storage declaration, and fix some places that synthesize
declarations to set it correctly.
Note that the bug was in Sema, but I added a SILGen test, since
that's an easy way to ensure the AST is valid.
Unfortunately the AST verifier does not perform many checks when
we emit diagnostics; adding the test case to an existing Sema test
would not catch regressions.
Fixes <rdar://problem/31595572>.
There is exactly one place where the 'skipClosures' needs to be
honored, and that is when applying the solution.
Also, teach typeCheckClosureBody to propagate failures
outward instead of ignoring them.
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
