If array literal type is not delayed and doesn't have any type variables
associated with it, let's prefer it over a disjunction to facilitate
type propagation through its `Element` type to element expressions.
Resolves: rdar://118993030
If key path type has bindings and is no longer delayed it means
that it's fully resolved and ready to be bound (even though value
type might not be resolved yet).
When `InferSendableFromCaptures` feature is enabled `inferKeyPathLiteralCapability`
should examine subscript arguments to determine whether the key path type is
sendable or not, and if so, inform inference to produce `& Sendable` existential
type as a binding. Binding key path type is delayed until all subscript arguments
are fully resolved.
This parameter doesn't allow direct holes because it always replies
on the contextual type (if it's not present the hole should be
propagated to it), so if we know that the argument is some invalid
existential value (one without a superclass) let's allow binding to
it only in diagnostic mode which would be detected and diagnosed as
a contextual mismatch.
Capability couldn't be determined for expressions like that which
means that inference should be delayed until root becomes available.
Resolves: https://github.com/apple/swift/issues/69936
If key path literal type is converted to a function type, it's
always the best course of action to use such a binding and forego
adding a KeyPath type binding based on capability because it
would never match.
This applies to invalid key pathes as well because we'd want to
propagate as much contextual information from the key path literal
into the context as possible.
Since key path root is now transitively inferred. Key path type
inference can be delayed until key path is resolved enough to
infer its capability.
This solves multiple problems:
- Inference fully controls what key path type is bound to;
- KeyPath constraint simplification doesn't have to double-check
the capability and attempt to re-bind key path type;
- Custom logic to resolve key path type is no longer necessary;
- Diagnostics are improved because capability and root/value type
mismatch are diagnosed when key path is matched against the
contextual type.
As a first step in delaying key path type until all of the members are
resolved, attempt to infer a type of root based on bindings associated
with key path type.
This flag makes it easier to determine what binding to produce
from the default. In cases where some of the member references
are invalid it's better to produce a placeholder for a key
path type instead of letting the solver to attempt to fix more
contextual problems for a broken key path.
This is a very first step in attempt to move some of the logic
from `simplifyKeyPathConstraint` to the inference. This type is
going to be used as an anchor to trigger capability inference.
Inference cannot be allowed in cases where both sides are type
variables and optional type is l-value capable because it results
in binding "optional" to an optional type and later discovering
a contextual type that is l-value optional i.e. if "optional type"
is resolved by selecting subscript overload.
Such types are not going to be applied by `ConstraintSystem::resolveClosure`
anyway and they impede diagnostics by forcing the solver to produce mutliple
equal solutions.
If type of the key path expression is convertible to an existential
value with a superclass constraint represented as a known key path
type, we can use it to inform key path inference.
Resolves: rdar://93103421
Conflicts:
- `CMakeLists.txt` caused by the extra `-D` added in rebranch to
reduce the number of deprecation warnings.
- `lib/Frontend/PrintingDiagnosticConsumer.cpp` caused by the removal
of one of the `#if SWIFT_SWIFT_PARSER` on rebranch (probably should
have been done on main).
`lookupConformance` request is not cached and constraint solver
performs a lot of them for the same type (i.e. during disjunction
solving), let's try to cache previously performed requests to
see whether additional memory use is worth the performance benefit.
Previously, default bindings (from Defaultable and FallbackType
constraints) where added to the set right after the first attempt,
but that is incorrect because binding producer should exhaust the
chain of superclasses and other "inferred" bindings first or risk
producing subpar solutions.
A type variable that represents a key path literal cannot be bound
directly to `AnyKeyPath` or `PartialKeyPath`, such types could only
be used for conversions.
It used to be the task of the binding inference to infer `AnyKeyPath`
and `PartiaKeyPath` as a `KeyPath` using previously generated type
variables for a root and value associated with key path literal
(previously stored in the locator).
Recently we switched over to storing key path information in the
constraint system and introduced `resolveKeyPath` method to gain
more control over how key path type variable gets assigned.
Getting information from the constraint system creates a problem
for the inference because "undo" for some bindings would be run
after solver scope has been erased, so instead of modifying bindings
in `inferFromRelational`, let's do that in `resolveKeyPath` right
before the key path type variable gets bound which seems to be a
better place for that logic anyway.
Resolves: rdar://113760727
llvm::SmallSetVector changed semantics
(https://reviews.llvm.org/D152497) resulting in build failures in Swift.
The old semantics allowed usage of types that did not have an
`operator==` because `SmallDenseSet` uses `DenseSetInfo<T>::isEqual` to
determine equality. The new implementation switched to using
`std::find`, which internally uses `operator==`. This type is used
pretty frequently with `swift::Type`, which intentionally deletes
`operator==` as it is not the canonical type and therefore cannot be
compared in normal circumstances.
This patch adds a new type-alias to the Swift namespace that provides
the old semantic behavior for `SmallSetVector`. I've also gone through
and replaced usages of `llvm::SmallSetVector` with the
`Swift::SmallSetVector` in places where we're storing a type that
doesn't implement or explicitly deletes `operator==`. The changes to
`llvm::SmallSetVector` should improve compile-time performance, so I
left the `llvm::SmallSetVector` where possible.
If a closure doesn't have a contextual type inferred yet it should
be delayed in favor of already resolved closure conjunction because
"resolving" such a closure early could miss result builder attribute
attached to a parameter the closure is passed to.
Partially resolves https://github.com/apple/swift/issues/67363
Ignore conversion score increases during code completion to make sure we don't filter solutions that might start receiving the best score based on a choice of the code completion token.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Rather than eagerly binding them to holes if the
sequence element type ends up being Any, let's
record the CollectionElementContextualMismatch fix,
and then if the patterns end up becoming holes,
skip penalizing them if we know the fix was
recorded. This avoids prematurely turning type
variables for ExprPatterns into holes, which
should be able to get better bindings from the
expression provided. Also this means we'll apply
the logic to non-Any sequence types, which
previously we would give a confusing diagnostic
to.
The constraint takes two pack types and makes sure that their
reduced shapes are equal. This helps with diagnostics because
constraint has access to the original pack expansion pattern
types.
It's only safe to infer element type from `PackElementOf` constraint
when pattern type is fully resolved (because it can have pack element
archetypes which should be mapped out of context), the same applies
to the pattern type inference as well. Since constraints are re-activated
every time a referenced type variable is bound, simplication logic
can act as inference source by decaying into `Equal` constraints
where pattern/element type are resolved via surrounding information
first.
