This is something I noticed by inspection while working on
<https://bugs.swift.org/browse/SR-75>.
Inside a static method, 'self' is a metatype value, so
'self.instanceMethod' produces an unbound reference of type
(Self) -> (Args...) -> Results.
You might guess that 'super.instanceMethod' can similarly
be used to produce an unbound method reference that calls
the superclass method given any 'self' value, but unfortunately
it doesn't work.
Instead, 'super.instanceMethod' would produce the same
result as 'self.instanceMethod'. Maybe we can implement this
later, but for now, let's just diagnose the problem.
Note that partially-applied method references with 'super.'
-- namely, 'self.staticMethod' inside a static context, or
'self.instanceMethod' inside an instance context, continue
to work as before.
They have the type (Args...) -> Result; since the self value
has already been applied we don't hit the representational
issue.
Let's delay attempting any bindings for type variables representing
parameters or result type of the closure until the body is "opened"
because it's impossible to infer a full set of bindings until all
constraints related to a closure have been generated.
Resolves: rdar://problem/59741308
Teach pattern matching involving "as" patterns to work properly in
function builders. The code almost handled this, but prematurely
prechecking expressions in patterns broke it.
Handle StmtCondition as part of SolutionApplicationTarget, so we can
generate constraints from it and rewrite directly as part of a solution,
rather than open-coding the operation in the function builder transform.
This was only required to represent an import that
hadn't yet had its scope validated. Now that the
validation has been requestified, we can directly
record the resulting `ImportedModuleDesc` instead.
Move the validation of scoped imports into a
request, and force the request when we're
type-checking a primary file. This has the nice
bonus of no longer running the validation for
secondary files.
The use of `ModuleDecl::getTopLevelModule` also
allows us to correctly retrieve the top-level
module for a Clang submodule, rather than
potentially retrieving the Swift module in a mixed
source project.
Resolves SR-12265.
Use the generalized constraint generation and binding for patterns to
introduce support for if-let and if-case in function builders, handling
arbitrary patterns.
Part of function builder generalization, rdar://problem/50426203.
Rather than re-walk the pattern to create type bindings for the variables
that show up in the pattern, assign types to each of the variables as part
of constraint generation for the pattern. Only do this in contexts
where we will need the types, e.g., function builders.
Fix a crash in dynamic member lookup attempting to recursively
lookup a member on the same base type.
The problem is related to `isSelfRecursiveKeyPathDynamicMemberLookup`
which failed to look through l-value wrapping base type on each side of
the comparison, that's important because it's possible to have l-value
mismatch due to the fact that implicit call always gets l-value base
type but actual subscript which triggered dynamic lookup might be r-value.
Resolves: [SR-11743](https://bugs.swift.org/browse/SR-11743)
Resolves: rdar://problem/57091169
When extracting substitutions during type lowering, we can't discard protocol constraints
in positions where the substitution is for a nominal type's generic arguments, since associated
types on that protocol may affect the nominal type's ABI.
Extend the constraint system’s diagnostics with specific handling for
matching an enum element pattern that has a subpattern (i.e., to capture
associated values) against an enum case that does not have any associated
value. This brings diagnostics for the new code path on par with the existing
diagnostics of coercePatternToType.
Generate a complete set of constraints for EnumElement patterns, e.g.,
case let .something(x, y)
Most of the complication here comes from the implicit injection of optionals,
e.g., this case can be matched to an optional of the enum type of which
`something` is a member. To effect this change, introduce a locator for
pattern matching and use it to permit implicit unwrapping during member
lookup without triggering an error.
Note also labels are dropped completely when performing the match,
because labels can be added or removed when pattern matching. Label
conflict are currently diagnosed as part of coercePatternToType, which
suffices so long as overloading cases based on argument labels is not
permitted.
The primary observable change from this commit is in diagnostics: rather
than diagnostics being triggered by `TypeChecker::coercePatternToType`,
diagnostics for matching failures here go through the diagnostics machinery
of the constraint solver. This is currently a regression, because
there are no custom diagnostics for pattern match failures within the
constraint system. This regression will be addressed in a subsequent
commit; for now, leave those tests failing.
Generate a checked-cast constraint for an “is” pattern, which otherwise
doesn’t change the type. This is hard to validate because checked-cast
constraints never actually fail.
