When this score kind was added, the marker for the last score kind was
not updated. As a result, increasing the score for SK_KeyPathSubscript
was not actually having an effect.
Add tests that include a type with subscripts that also take the key
paths as their argument with an identical argument label ("keyPath").
These tests show that we're actually falling back on the keypath
application in many cases despite the score kind specific to keypath
application. I'll open a couple new JIRAs to investigate this
behavior.
The update to SK_LastScoreKind results in fixing a crash in these tests
that happens as a result of an assumption in CSRanking.cpp that if we're
comparing two solutions we end up with decls for overloads to compare,
which isn't the case here due to the keypath application.
Once we're finalizing same-type-to-concrete and superclass
constraints, replace any unresolved DependentMemberTypes with their
resolved counterpairs. This allows us to simplify
DependentGenericTypeResolver, which only builds unresolved
DependentMemberTypes now, and eliminates the penultimate use of
ArchetypeResolutionKind::AlwaysPartial.
When resolving archetypes using the "always partial" resolution kind,
we allow the system to form potential archetypes which might be
invalid. Start limiting the use of this "always partial" resolution
kind, so that it can eventually be removed entirely to simplify the
invariants of the GenericSignatureBuilder.
Each of the callers should either be working with complete,
well-formed archetypes or they should not force any resolution this
early.
Instead of validating sub-expressions included in the closure's result
`diagnoseAmbiguousMultiStatementClosure` was only checking parent expression
by mistake.
ValueDecl::getInterfaceType() asserts if the decl has no interface
type; to check if the declaration has been type checked yet, use
hasInterfaceType().
Fixes <https://bugs.swift.org/browse/SR-4743>.
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
This changes `getBaseName()` on `DeclName` to return a `DeclBaseName`
instead of an `Identifier`. All places that will continue to be
expecting an `Identifier` are changed to call `getBaseIdentifier` which
will later assert that the `DeclName` is actually backed by an
identifier and not a special name.
For transitional purposes, a conversion operator from `DeclBaseName` to
`Identifier` has been added that will be removed again once migration
to DeclBaseName has been completed in other parts of the compiler.
Unify approach to printing declaration names
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
Consolidate some of the attributes and operations common to disjunction choice
in new `DisjunctionChoice` class, which simplifies implementation of the
`ConstraintSystem::solveSimplified` method related to overload selection.
The old TVO_MustBeMaterializable is now equivalent to
!TVO_CanBindToLValue && !TVO_CanBindToInOut.
I tried to update all usages of createTypeVariable() to
pass TVO_CanBindToInOut unless they explicitly passed
TVO_MustBeMaterializable before.
However, in reality TVO_CanBindToInOut is the rare case;
we can remove this flag gradually over time to fix
crashes and diagnostics.
Instead, introduce a new hasDependentMember() recursive property.
The only place that cares about this is associated type inference,
where I changed all existing hasTypeParameter() checks to instead
check (hasTypeParameter() || hasDependentMember()). We could
probably refine this over time and remove some of the
hasTypeParameter() checks, but I'm being conservative for now.
Fixes <https://bugs.swift.org/browse/SR-4575> and
<rdar://problem/31603113>.
If synthesizeWitnessAccessorsForStorage() got called on a lazy
property before maybeAddAccessorsToVariable(), we would build
it as a stored property instead.
This count result in bogus diagnostics, assertions and bad runtime
behavior.
Fixes <https://bugs.swift.org/browse/SR-1825>.
Enum elements have to be treated the same way as regular functions
when passed as values, which means labels have to be stripped from
their argument types.
Resolves: rdar://problem/32300339.
Dispatch requests the ability to add a new case, but to treat missing
instances of that case in patterns as warnings instead of errors. It is
still an error to make reference to the annotated case in at least one
pattern then not cover the rest of the space, but it is not an error
to omit the space of patterns referencing the case entirely.
This attribute is private and uglified to intentionally discourage
its use outside just this one use case.
To further cut down on the number of cases present,
add a filter that catches if the flattening algorithm ever hands us back
a pattern matrix that contains duplicate entries. Note that this does
not, by definition, affect pattern completeness.
Allow instance properties and methods to be referenced from
within a lazy property initializer, with or without explicit
'self.' qualification.
The old behavior in Swift 3 was an incredible combination
of odd quirks:
- If the lazy property had an explicitly-written type, it was
possible to reference instance members from the initializer
expression by explicitly prefixing 'self.'.
- However, if the lazy property type is inferred, it would
first be type checked in the initializer context, which
has no 'self' available.
- Unqualified references to instance members did not work
at all, because name lookup thought the "location" of the
lookup was outside of the body of the getter.
- Unqualified references to static properties worked, however
unqualified references to static methods did not, and
produced a bogus diagnostic, because one part of the name
lookup code thought that initializers were "instance
context" and another thought they were "static context".
This patch improves on the old behavior with the following
fixes:
- Give PatternBindingInitializers associated with lazy
properties an implicit 'self' declaration for use by
name lookup.
- In order to allow "re-parenting" the initializer after it
has been type checked into the body of the getter, "steal"
the initializer's 'self' when buiding the getter.
- Fix up name lookup and make it aware of the implicit
'self' decl of a PatternBindingInitializer.
This improves upon an earlier fix for this issue by Doug Gregor
which only worked with ASTScope enabled; the new fix is more
general and shares logic between the two name lookup
implementations.
Fixes <rdar://problem/16888679>, <https://bugs.swift.org/browse/SR-48>,
<https://bugs.swift.org/browse/SR-2203>,
<https://bugs.swift.org/browse/SR-4663>, and the countless other
dupes of this issue.
If a lazy var has no declared type, we have to type check the
initializer to get a type before we can build the getter.
Then, the initializer is type checked as part of the getter
again.
Use the new SkipApplyingSolution flag when type checking for
the first time. We still end up doing redundant work, but by
not applying the solution we avoid feeding invalid AST nodes
back into the constraint solver.
This fixes some bad diagnostics and crashes.
Fixes <https://bugs.swift.org/browse/SR-2616> and
<rdar://problem/28313602>.
Record the initializer type as soon as we have a solution, before
it is applied, and get the type from the constriant system instead
of from the final type checked expression.
Note that the coerceToMaterializable() was unnecessary, since we
always coerce the value to an rvalue type with coerceToType().
Eventually coerceToMaterializable() should go away.
This is mostly NFC, except using the result of simplifyType() rather
than the type of the final expression changes some diagnostics where it
appears we were previously losing sugar.
Also this accidentally fixes a crasher. Unfortunately the underlying
issue is still there (applying a solution has bugs with opened
existentials "leaking" out) -- this merely masks the problem by
getting the initializer type directly from the constriant system.
This introduces a new TypeCheckExprFlags::SkipApplyingSolution flag,
and a ExprTypeCheckListener::foundSolution() that is invoked before
the solution is applied.
While the existing getTypeOfExpressionWithoutApplying() method is
similar, it's tailored for diagnostics and has some hacks in it.
It should be refactored to use the new mechanism I added.
And make an attempt to use the constraint system's contextualType to bind type information; this makes things better but doesn't seem to be a complete solution for contextually typing key paths.
We don't actually want to open the type; instead, calculate the
substituted member type using substMemberTypeWithBase(), which
will return an unbound generic type if the member is a generic
nominal or type alias, and then it open it with openUnboundGenericType().
This is NFC for now, but I need generic typealiases to come in as
UnboundGenericTypes here in a subsequent patch.
The openType() function did two things:
- Replace unbound generic types like 'G' with fresh type variables
applied to bound generic types, like 'G<$T0>'.
- Replace generic parameters with type variables from the replacement
map.
The two behaviors were mutually exclusive and never used from the
same call site, so split them up into two independent functions.
Also, eliminate ConstraintSystem::openBindingType() since it was only
used in one place and could be expressed in terms of existing functions.
Now that preCheckExpression() can handle more cases, we can
eliminate a special case where sometimes we would make
DeclRefExprs instead of TypeExprs for references to generic
types.
