Fixes crasher #003 (rdar://problem/18232605). This time, also increase the buffer size for the necessary bindings so we don't clobber memory.
Swift SVN r22118
(If any other associated type member has a dependency on the invalid one, we won't be able to substitute and the compiler will crash.)
This addresses crash suite scenario 035. (rdar://problem/18233020)
Swift SVN r22116
You'll notice that we already had tests that made it appear that such declarations could work,
but they were only avoiding crashes because downstream errors were already marking the
enclosing functions as invalid. (If the errors were fixed, they would also crash the compiler.)
This addresses crash suite scenario 018. (rdar://problem/18299547)
Swift SVN r22109
There's no real use for declaring a property or global variable without binding it to anything, and closure context mangling relies on having a name to associate with closures. Fixes crash suite #006 (rdar://problem/18232699).
Swift SVN r22105
Doing so prevents another common source of stack overflows in the validator, and addresses crash suite scenarios 002 and 004.
(rdar://problem/18232499, rdar://problem/18232668)
Swift SVN r22104
This can only occur when validating mutually recursive existentials in type reference expressions, so it's "safe" to avoid validating member value decls in this case. There are still potential holes in our mechanism for checking for unsupported existentials, but at least this will eliminate another common crasher. (Crash suite scenario 010.)
Swift SVN r22035
Now that we rely on type lowering to catch recursive value types, this optimization is no longer valid. Fixes rdar://problem/18232757 (crash suite #015).
Swift SVN r21967
- A spot fix in SILGen for reabstracting the result of a downcast, which fixes checked casts to function types.
- Associate the layout information in type metadata records with the most abstract representation of the type. This is the correct thing to do in cases where we need the metadata as a tag for an opaque value--if we store a value in an Any, or pass it as an unconstrained generic parameter, we must maximally reabstract it. This fixes the value semantics of existentials containing trivial metatypes.
- To ensure that we get runtime layout of structs and enums correct when they contain reabstractable types, introduce a "metadata for layout" concept, which doesn't need to describe the canonical metadata for the type, but only needs to describe a type with equivalent layout and value semantics. This is a correctness fix that allows us to correctly lay out generic types containing dependent tuples and functions, and although we don't really take advantage of it here, it's also a potential runtime performance win down the road, because we could potentially produce direct metadata for a primitive type that's layout-equivalent with a runtime-instantiated type. To aid in type safety here, push SILType deeper into IRGen in places where we potentially care about specific representations of types.
- Finally, fix an inconsistency between the runtime and IRGen's concept of what spare bits unmanaged references and thick metatypes have.
Together, these fixes address rdar://problem/16406907, rdar://problem/17822208, rdar://problem/18189508, and likely many other related issues, and also fixes crash suite cases 012 and 024.
Swift SVN r21963
You'll notice that emitting this diagnostic will make some already noisy closure-related errors slightly more so. This is unfortunate, but for the time-being it's better than crashing.
Swift SVN r21817
We're going to crash anyway, we'll fix it when we fix the main issue, and
the main issue isn't memory-error-related. Should unblock the ASan bot.
Swift SVN r21814
