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.
Although variadic type is declared without `repeat` each of
its generic arguments is supposed to be a PackType which is
modeled in the interface type as `Pack{repeat ...}`. When
reference to such a type is opened by the constraint solver
we need to drop the Pack{repeat ...} structure because the
type variable would represent a pack type so `S<each T>`
is opened as `S<$T0>` instead of `S<Pack{repeat $T0}>`.
Resolves: https://github.com/apple/swift/issues/66095
Binding of pack expansion types is delayed until solving but use
of `Defaultable` was preventing it from being considered early
because that constraint impacts binding set ranking, switching
to `FallbackType` constraint give us better semantics where pack
expansion type variables are going to be bound as soon as they
have a contextual type.
Resolves: rdar://110819621
If generic parameter gets opened during regular solving it cannot
be bound to a hole, that can only happen in diagnostic mode, so
let's not even try. Doing so also makes sure that there are no
inference side-effects related to holes because bindings are ranked
based on their attributes.
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
There's still plenty of more work to do here for
pattern diagnostics, including introducing a
bunch of new locator elements, and handling things
like argument list mismatches. This at least lets
us fall back to a generic mismatch diagnostic.
If function type of some declaration has a at least on type parameter
pack it could mean that number of parameters in "applied" type could
be different from that of "interface" type.
If there are multiple overloads, let's skip locations that produce
the same type across all of the solutions, such location is most
likely a consequence of ambiguity and not its source.
Resolves: rdar://109245375
Opened existentials should be erased to the dependent upper bound
if the dependent member can be reduced to a concrete type. This
allows the generic signature to support parameterized protocol types
and bound generic class types by producing a more specific constraint
instead of just a plain protocol or class.
If there are explicit generic arguments that fully resolves the
pack expansion, let's bind opened pack expansion to its contextual
type early (while resolving pack expansion variable), doing so
helps with performance and diagnostics.
`openType` didn't need a locator before it was simply replacing generic
parameters with corresponding type variables but now, with opening of
pack expansions types, a locator is needed for pack expansion variables.
Replace all `PackExpansionType` with a special type variable
which would be resolved once the solver determines that there
is enough contextual information.
Pack expansion type variable can only ever have one binding
which is handled by \c resolvePackExpansion.
There is no need to iterate over other bindings here because
there is no use for contextual types (unlike closures that can
propagate contextual information into the body).
If a pattern type of a pack expansion doesn't have all of the "pack capable"
type variables bound, we don't know what the structure is yet and expansion
cannot be flattened.
Models `PackExpansionType` as a type variable that can only
bind to `PackExpansionType` and `expansion of` constraint that
connects expansion variable to its pattern, shape types.
Only fully resolved substitutions are eligible to be considered
as conflicting, if holes are involved in any position that automatically
disqualifies a generic parameter.
Resolves: rdar://108534555
Resolves: https://github.com/apple/swift/issues/63450
`openGenericParameters` calls `bindArchetypesFromContext` which would bind all of the
external generic parameters in the opaque type signature.
Resolves: rdar://107280056
Substitution of a pack expansion type may now produce a pack type.
We immediately expand that pack when transforming a tuple, a function
parameter, or a pack.
I had to duplicate the component-wise transformation logic in the
simplifyType transform, which I'm not pleased about, but a little
code duplication seemed a lot better than trying to unify the code
in two very different places.
I think we're very close to being able to assert that pack expansion
shapes are either pack archetypes or pack parameters; unfortunately,
the pack matchers intentionally produce expansions of packs, and I
didn't want to add that to an already-large patch.
Enforce that we don't have any type variables
present in either the result or parameter types.
To ensure the constraint system doesn't violate
this invariant, refactor `getTypeOfMemberReference`
slightly to avoid construction of a
`GenericFunctionType` as a means of opening the
generic parameters of the context for a VarDecl.
