New GenericTypeParamDecls should always be created with an
InvalidDepth, to prevent canonicalization before the generic
parameter list has been type checked.
If typechecking fails, the expression will have unsolved type variables
written into it. This Crashes The Compiler.
In that case, there’s no reason to keep a tree of dangling references
around. Detach the initializer expression from the AST, but continue
to typecheck it to see if we can get some useful diagnostics out of it.
TypeChecker::applyUnboundGenericArguments() did not call
checkGenericArguments() when applying arguments to a generic
typealias. This would cause bad diagnostics or AST verifier
failures if the arguments did not match the requirements of
the typealias.
Add the missing check and converge the two different code paths
inside this function; the code for generic typealiases was
actually more general, and subsumes the nominal type case
entirely.
Fixes <rdar://problem/29061136>.
addImplicitConstructors() will crash if validateDecl() does not produce
a valid signature for one of the class's constructors because the
constructor is already being validated.
This was triggered during associated type inference in the test case
in the radar.
Fixes <rdar://problem/30751491>.
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
1. Make sure the actions taken by fixits are reflected in diagnostics messages.
2. Issue missing cases diagnostics at the start of the switch statement instead of its end.
3. Use <#code#> instead of <#Code#> in the stub.
This allows a library to "fix" an initializer that should have been
failable or non-failable by gating the change on the user's version of
Swift. Failability (and whether or not the initializer throws) is
something that doesn't change the "overload signature", so normally
the compiler would call this an invalid redeclaration. But since only
one version can be active at a time based on the client context, there
won't be a problem in practice.
https://bugs.swift.org/browse/SR-4171 / rdar://problem/30470854
I realized in the process of doing this that methods may also have
mismatched 'throws', and we should allow that as well. Next commit.
This argument treated the pointer value as an "allow invalid" flag,
meaning the search could turn up a 'dynamic' attribute that was
already marked invalid. In practice this will probably affect absolutely
no one, but the old code was still wrong.
It is generally useful to allow 'super' method calls inside a
closure, so you can have overrides that do things like:
override func foo() {
doSomething { super.foo() }
}
However this didn't work if the closure was a local generic
function because we didn't map the 'super' type into the
right generic context.
SourceKit always sets it positively. This may lead to more aggressive fixits however
less informative messages. We currently use the flag only for filling protocol stubs.
ASTContext::getSpecializedConformance() already copies the
substitutions, so remove some AllocateCopy() calls.
Also, add a new overload taking a SubstitutionMap instead.
This allows removing some gatherAllSubstitutions() calls,
which have an allocation inside them.
Finally, remove the now-unused ModuleDecl parameter from
ProtocolConformance::subst() and make it public.
Introduce an API that determines the "conformance access path" that
one would follow to find the conformance of a given type parameter
(e.g., T.Iterator.Element) to a given protocol (e.g., Equatable). A
conformance access path starts at one of the explicit requirements
of that generic signature and then proceeds through zero or more
protocol-supplied requirements. For example, given this function:
func f<C: Collection>(_: C) { }
The conformance access path for "C.Iterator: IteratorProtocol" is
(C, Collection) -> (Self, Sequence) -> (Self.Iterator, IteratorProtocol)
because one starts with the explicit requirement "C: Collection", goes
to the inherited protocol requirement (the "Self" in Collection
conforms to Sequence) and then a requirement on the associated type
(Self.Iterator in Sequence conforms to IteratorProtocol).
This is all scaffolding now; it's intended to be used by IRGen (to
find the witness tables it needs) and SubstitutionMap (to dig out
conformances during substitution).
The ad hoc substitution functions here were really odd; use
SubstitutionMap directly, and pass it through to
GenericSignatureBuilder::addRequirement().
We have a quirk where TypeBase::getSuperclass() on DynamicSelfType
returns the underlying class type, and not the superclass of the
underlying class type. As a result, we would emit a SuperRefExpr
whose type was the type of 'self' and not the type of 'super'.
Fixes <rdar://problem/30853768>.
