It's useful to know what the open type variables in a generic protocol conformance are. For now, make the somewhat shaky assumptions that a NormalProtocolConformance for a bound generic type is for the DeclaredTypeInContext of its originating nominal type, that all type variables of the nominal type are open, and that specialized and inherited conformances bind all of the generic parameters.
Swift SVN r11274
Walk the ProtocolConformances of type and extension decls to produce SILWitnessTables for them. Work out the type of the witness function by applying substitutions from the witness map and lowering it at the abstraction level of the requirement, then emit a symbol for the witness function (but don't emit the body of the witness function just yet).
Swift SVN r11143
Part of the FileUnit restructuring. A Clang module (whether from a framework
or a simple collection of headers) is now imported as a TranslationUnit
containing a single ClangModuleUnit.
One wrinkle in all this is that Swift very much wants to do searches on a
per-module basis, but Clang can only do lookups across the entire
TranslationUnit. Unless and until we get a better way to deal with this,
we're stuck with an inefficiency here. Previously, we used to hack around
this by ignoring the "per-module" bit and only performing one lookup into
all Clang modules, but that's not actually correct with respect to visibility.
Now, we're just taking the filtering hit for looking up a particular name,
and caching the results when we look up everything (for code completion).
This isn't ideal, but it doesn't seem to be costing too much in performance,
at least not right now, and it means we can get visibility correct.
In the future, it might make sense to include a ClangModuleUnit alongside a
SerializedASTFile for adapter modules, rather than having two separate
modules with the same name. I haven't really thought through this yet, though.
Swift SVN r10834
The goal of this series of commits is to allow the main module to consist
of both source files and AST files, where the AST files represent files
that were already built and don't need to be rebuilt, or of Swift source
files and imported Clang headers that share a module (because they are in
the same target).
Currently modules are divided into different kinds, and that defines how
decls are looked up, how imports are managed, etc. In order to achieve the
goal above, that polymorphism should be pushed down to the individual units
within a module, so that instead of TranslationUnit, BuiltinModule,
SerializedModule, and ClangModule, we have SourceFile, BuiltinUnit,
SerializedFile, and ClangUnit. (Better names welcome.) At that point we can
hopefully collapse TranslationUnit into Module and make Module non-polymorphic.
This commit makes SourceFile the subclass of an abstract FileUnit, and
makes TranslationUnit hold an array of FileUnits instead of SourceFiles.
To demonstrate that this is actually working, the Builtin module has also
been converted to FileUnit: it is now a TranslationUnit containing a single
BuiltinUnit.
Swift SVN r10830
decl context of the type alias.
This implements <rdar://problem/15290346> "typealias sugar needs to be
mangled into debug info mangled type names".
Swift SVN r10749
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
