innermost DeclContext of the decl that uses the archetype instead of the
actual generic context of the archetype.
<rdar://problem/15453889> Qualified archetypes mangle wrong DeclCtx
Swift SVN r10470
Instead of hardcoding Builtin.Word to be an alias for Builtin.Int64, make it its own type of abstract pointer width.
- Change BuiltinIntegerType's width representation to accommodate abstract widths.
- In the AST and in SIL, store values of the types as the greatest supported size for the abstract width (64 bits for a pointer).
- Add some type safety to the ([sz]ext|trunc)(OrBitCast)? builtins that they're used appropriately given the upper and lower bounds of the abstract sizes they're working with.
- Now that Builtin.Word is a distinct type, give it its own mangling.
- In IRGen, lower pointer-sized BuiltinIntegerType appropriately for the target, and truncate lowered SIL values if necessary.
Fixes <rdar://problem/15367913>.
Swift SVN r10467
used only for debug info and within the _Tt namespace.
The DWARF output created by swift is intentionally flat, therefore
archetypes need to be emitted with their DeclContext. While increasing the
length of the mangled names in some cases (substitutions help a lot) it
has the advantage of making names completely self-contained.
There is a lengthy thread on swift-debugger discussing this change.
Swift SVN r10348
Pull the implicit 'Self' associated type out of the protocol and into
an implicitly-declared generic parameter list for the protocol. This
makes all of the methods of a protocol polymorphic, e.g., given
protocol P {
typealias Assoc
func getAssoc() -> Assoc
}
the type of P.getAssoc is:
<Self : P> (self : @inout P) -> () -> Self.Assoc
This directly expresses the notion that protocol methods are
polymorphic, even though 'Self' is always implicitly bound. It can be
used to simplify IRgen and some parts of the type checker, as well as
laying more of the groundwork for default definitions within
protocols as well as sundry other improvements to the generics
system.
There are a number of moving parts that needed to be updated in tandem
for this. In no particular order:
- Protocols always get an implicit generic parameter list, with a
single generic parameter 'Self' that conforms to the protocol itself.
- The 'Self' archetype type now knows which protocol it is
associated with (since we can no longer point it at the Self
associated type declaration).
- Protocol methods now get interface types (i.e., canonicalizable
dependent function types).
- The "all archetypes" list for a polymorphic function type does not
include the Self archetype nor its nested types, because they are
handled implicitly. This avoids the need to rework IRGen's handling
of archetypes for now.
- When (de-)serializing a XREF for a function type that has an
interface type, use the canonicalized interface type, which can be
meaningfully compared during deserialization (unlike the
PolymorphicFunctionType we'd otherwise be dealing with).
- Added a SIL-specific type attribute @sil_self, which extracts the
'Self' archetype of a protocol, because we can no longer refer to
the associated type "P.Self".
Swift SVN r9066
Rewrite ForEachStmt SILGen to use the Optional intrinsics with the Generator.next method to iterate through sequences, and kill off the Enumerator path in Sema. Cut over 'EnumeratorType.Element' requirements to instead require 'GeneratorType.Element' in the stdlib.
There are a couple of bugs remaining that need follow-up work. There appears to be a bug in nested enum layout (e.g. T??) that's causing test/Interpreter/enum to break; I'll investigate and fix. There's also a lingering type-checker bug with inferred associated types that causes them to fail requirement checks <rdar://problem/15172101>, which I think Doug needs to look into.
Swift SVN r9017
Introduces a new kind of function type, GenericFunctionType, that
represents a polymorphic function type with all of its generic
parameters and requirements stored in a more readily canonicalizable
form. It is meant to eventually replace PolymorphicFunctionType, but
for now we build it up in parallel so we can switch over to it
pieacemeal.
Note: this representation is built and then thrown away. We'll start
recording it soon.
Swift SVN r8881
This is only useful for unique-identification uses of the mangler, like in SourceKit,
which has to deal with invalid code.
Since this is not related to ABI, we can change the encoding anytime we want.
Swift SVN r8557
