Previously, methods on DeclContext for getting generic parameters
and signatures did not walk up from type contexts to function
contexts, or function contexts to function contexts.
Presumably this is because SIL doesn't completely support nested
generics yet, instead only handling these two special cases:
- non-generic local function inside generic function
- generic method inside generic type
For local functions nested inside generic functions, SIL expects
the closure to not have an interface type or generic signature,
even if the contextual type signature contains archetypes.
This should probably be revisited some day.
Recall that these cases are explicitly rejected by Sema diagnostics
because they lack SIL support:
- generic function inside generic function
- generic type inside generic function
After the previous patches in this series, it becomes possible to
construct types that are the same as before for the supported uses of
nested generics, while introducing a more self-consistent conceptual
model for the unsupported cases.
Some new tests show we generate diagnotics in various cases that
used to crash.
The conceptual model might still not be completely right, and of
course SIL, IRGen and runtime support is still missing.
Once nested generic parameter lists are properly chained, we need a
way of checking if we're inside a generic type context that's
distinct from just checking if we have a generic type signature
available.
This distinguishes between these two cases:
class A<T> {
// generic signature
func method() -> T { // <T> A<T> -> () -> T
}
}
func f<T>() {
class A {
// no generic signature
func method() -> T { // A -> () -> T
}
}
}
This would just set the NominalTypeDecl's declared type to
ErrorType, which caused problems elsewhere.
Instead, generalize the logic used for AbstractFunctionDecl.
This correctly wires up the GenericTypeParamDecl's archetypes even
if the signature didn't validate, fixing crashes if the generic
parameters of the type are referenced.
An invalid `case` construct would incorrectly return a successful status, causing `parseDecl` to crash later when it assumed there were valid decls in the `Entries` vector.
This time, the issue is that TypeNullifier skips bodies of
multi-statement closures. However, ExprRewriter will type
happily pass them on to typeCheckClosureBody(). This could
trigger assertions. Fix this by skipping type checking of
multi-statement closures when diagnosing.
There seems to be a minor QoI regression in some test cases
that already looked pretty dodgy and/or had FIXMEs. However
I think its worth fixing a crash.
This crashing test became non-crashing in #138. #138 also emitted multiple instances of the same diagnostic, which was causing -verify to fail on decl/protocol/req/recursion.swift.
This reverts commit e0b4d55545.
Revert "Include crashing test case"
This reverts commit e5dd189aaf.
Revert "Compare rvalue types in assertion"
This reverts commit 1952739f9d.
This series of commits still was leading to a crash in IRGen.
There is an incorrect ref_to_unmanaged further up in the function
with the wrong input type, so something is weird with preparing
the AutoreleasingUnsafeMutablePointer.
https://bugs.swift.org/browse/SR-87
