Early on in the development of conditional conformances, we put in a bunch
of assertions for code that uses `conformsToProtocol()` but wasn't handling
conditional conformances. Now, `conformsToProtocol()` handles conditional
conformances by default, and these assertions are tripping up code
that would work.
Remove the assertions and add test cases that used to trip up the
assertions (but now work).
These purportedly mark that we should stop attempting fixes for a given
constraint, but in fact the only code creating these is clearly
unreachable so these serve no purpose.
conformsToProtocol() is the main way in which we check whether a given type
conforms to a given protocol. Extend it to check conditional requirements by
default, so that an unmodified caller will get the "does not conform" result
(with diagnostics when a location is present) rather than simply ignoring
the conditional requirements.
Some callers take responsibility for conditional requirements, e.g., to
push them into the constraint system. Allow those callers to opt out of
this checking, and do so wherever appropriate.
Fixes rdar://problem/35518088, where we were ignoring the conditional
requirements needed to verify that Equatable synthesis could be performed.
Fix problem related to Swift 3 mode (with assertions),
since Swift 3 mode allows passing arguments with extra parens
to parameters which don't expect them, it should be supported
by "deep equality" types e.g. Optional<T>:
```swift
func foo(_: (() -> Void)?) {}
func bar() -> ((()) -> Void)? { return nil }
foo(bar) // This expression should compile in Swift 3 mode
```
Resolves: rdar://problem/35198459
Consider different overload choices for the same location in evaluation
order, this makes overload resolution more predictable because it's going
to follow expression bottom-up, that prevents situations when some
expressions are considered ambigious because choices taken further up
equate the score, instead each level is given distinct weight
based on evaluation order.
Resolves: rdar://problem/31888810
When testing KeyPathApplication constraints, we would keep going after rejecting a concrete KeyPath application by trying PartialKeyPath and AnyKeyPath, even though that's not what we want, since any key path application expression can type check with an AnyKeyPath. We would then miscompile by building the AST such that we applied the mismatched key path expression directly to the base. We also didn't handle expressions where the base was a subtype of the key path's base type correctly—the conversion means the base can't be written through in this situation, and we hardcoded the concrete-to-existential case instead of handling general conversions. Fix these problems, and add an AST verifier for KeyPathApplicationExprs to help catch problems in the future. Fixes SR-6300 | rdar://problem/35368903.
* If we have an updatable ClosureExpr, then both fromEI.isAutoClosure()
and toEI.isAutoClosure() must be false because the type system ensures
that normal closures and functions do not convert to auto-closures.
* If we have a throwing ClosureExpr, then fromEI.throws() and
toEI.throws() must be true, otherwise an erroneous throwing to
non-throwing closure/function conversions would be possible. From a
different perspective, updating the 'throws' bit would make sense if
overloading on 'throws' wasn't possible.
Except GenericEnvironment.h, because you can't meaningfully use a
GenericEnvironment without its signature. Lots less depends on
GenericSignature.h now. NFC
This allows determining which requirements make a conformance conditional; as
in, which requirements aren't known as part of the type itself.
Additionally, use this to assert that a few builtin protocols aren't
conditionally-conformed-to, something we won't support for now.
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.
