1. Array type parsing for postfix array types Int[]. We now handle this
in the parser, but remove the AST representation of this old form. We
also stop making vague promises about the future by saying that "fixed
size arrays aren't supported... yet". Removal of this fixes a compiler
crasher too.
2. Remove the special case support for migrating @autoclosure from types
to parameters, which was Swift 1.0/1.1 syntax. The world has moved or
we don't care anymore.
3. Remove upgrade support for # arguments (nee "backtick" arguments), which
was a Swift 1.x'ism abolished in an effort to simplify method naming
rules.
NFC on valid code.
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.
History:
* Marked as fixed in the swift-compiler-crashes project in February 2015 - does not crash Xcode 6.3 beta with Swift 1.2 (6D520o).
* Re-opened as regression in December 2015 - crashes Swift version 2.2-dev (LLVM 7bae82deaa, Clang 53d04af5ce, Swift 56a62b7eef).
Possible memory corruption:
dmesg:
swift[10043]: segfault at 8 ip 000000000100e5f0 sp 00007ffca9045200 error 4 in swift[400000+3d82000]
valgrind:
==18826== Process terminating with default action of signal 11 (SIGSEGV)
==18826== Access not within mapped region at address 0x8
==18826== at 0x100E5F0: swift::TypeBase::getDesugaredType() (in /path/to/swift/bin/swift)
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.
