If a Swift key path has root type inferred but does not have a leading dot,
then diagnose it, because it's not valid.
For example:
```swift
struct Foo {
let property: [Int] = []
let kp: KeyPath<Foo, Int> = \property.count // error
}
```
Resolves SR-12290
Resolves rdar://problem/59874355
Instead of setting empty closure (`{}`) result type to be `Void`
while generating constraints, let's allocate a new type variable
instead and let it be bound to `Void` once the body is opened.
This way we can support an interaction with function builders which
would return a type different from `Void` even when applied to empty closure.
Resolves: rdar://problem/61347993
* [CSDiagnostics] Handle arg to param generic when locator points to ConstraintLocator::GenericArgument
* [test] Add SR-12242 test case
* [CSDiagnostics] Handle arg to param on Generic mismatch as a fallback diagnostic
* [CSDiagnostics] Make assign diagnostics in GenericMismatchFailure handle more cases
* [test] Adding test cases for assign expr in GenericMismatch diagnostics
* [CSDiagnostics] Improving inout to pointer argument conversions with optionals diagnostics
Previously we were bailing early on encountering
an optional chain in the key path. However this
could cause us to miss invalid components further
down the line. Instead, set a flag and force the
key path to be read-only if we encountered an
optional chain.
Resolves SR-12519.
Start fixing SR-12526: `@derivative` attribute cross-module deserialization
crash. Remove original `AbstractFunctionDecl *` from `DerivativeAttr` and store
`DeclID` instead, mimicking `DynamicReplacementAttr`.
Lift temporary cross-file derivative registration restriction.
`@derivative` attribute type-checking simplications coming soon: TF-1099.
Original function and derivative function must have same access level, with one
exception: public original functions may have internal `@usableFromInline`
derivatives.
wrapper original wrapped value expression inside of CSApply.
This prevents type checking the synthesized backing storage initializer
twice - once with the original expression and again with the placeholder.
Like switch cases, a catch clause may now include a comma-
separated list of patterns. The body will be executed if any
one of those patterns is matched.
This patch replaces `CatchStmt` with `CaseStmt` as the children
of `DoCatchStmt` in the AST. This necessitates a number of changes
throughout the compiler, including:
- Parser & libsyntax support for the new syntax and AST structure
- Typechecking of multi-pattern catches, including those which
contain bindings.
- SILGen support
- Code completion updates
- Profiler updates
- Name lookup changes
Unfortunately we still need this performance hack because otherwise
e.g. if initializer returns a tuple its type is going to be connected
to a type variable representing a pattern type, which means all of the
tuple element types are going to form a single constraint system component.
Resolves: rdar://problem/60961087
In each of the following situations `getTypeForPattern` would
add a new pattern element to the path:
- Element of a tuple pattern
- Sub-pattern of a typed pattern
- Sub-pattern of optional .some
We used to take all the captures of a local function and treat them all
as read and write usages of vars from an outer scope. Instead, let's
refactor the analysis to walk into local functions.
Type erasure requires a circular construction by its very nature:
@_typeEraser(AnyProto)
protocol Proto { /**/ }
public struct AnyProto : Proto {}
If we eagerly resolve AnyProto, the chain of resolution steps that
deserialization must make goes a little something like this:
Lookup(Proto)
-> Deserialize(@_typeEraser(AnyProto))
-> Lookup(AnyProto)
-> DeserializeInheritedStuff(AnyProto)
-> Lookup(Proto)
This cycle could be broken if the order of incremental inputs was
such that we had already cached the lookup of Proto.
Resolve this cycle in any case by suspending the deserialization of the
type eraser until the point it's demanded by adding
ResolveTypeEraserTypeRequest.
rdar://61270195
Before attempting to get the superclass of a
self parameter type, check to see if we have a
metatype, and perform the necessary unwrapping and
re-wrapping if needed.
Previously, two conditions were necessary to enable differentiable programming:
- Using the `-enable-experimental-differentiable-programming` frontend flag.
- Importing the `_Differentiation` module.
Importing the `_Differentiation` module is the true condition because it
contains the required compiler-known `Differentiable` protocol. The frontend
flag is redundant and cumbersome.
Now, the frontend flag is removed.
Importing `_Differentiation` is the only condition.
When a Swift declaration witnesses an ObjC protocol requirement, its error convention needs to
match the requirement. Furthermore, if there are different protocol requirements that the
Swift method can witness, with different error conventions, we need to bail out because we
can't simultaneously match all of them. Fixes rdar://problem/59496036 | SR-12201.
The ContextualizeClosures walker re-parents and assigns discriminators to
autoclosures. We weren't doing this walk for function builder bodies,
which meant that proper invariants were not being established for the
implicit autoclosures synthesized for partially applied method references.
This is a recent regression from my change to build curry thunks for
unapplied method references in Sema.
Fixes <rdar://problem/61039516>.
