This isn't testable yet, as it is blocked by at least two things:
1. we can't put curried functions into witness tables (rdar://16079147),
which is a problem given that subscript accessors are curried on their
index argument.
2. accessors cannot silgen is curried form, we currently die in mangling.
Swift SVN r13947
Given our constraints for 1.0, we can actually sort-of look up protocol conformances just by dlsym'ing the symbol for their protocol witness table, since we won't be implementing runtime witness table instantiation or private conformances anytime soon. To make this work for generic types, distastefully regress our mangling for protocol conformances by assuming all generic conformances are completely general to the unbound generic type and leave the generic parameters out of the mangling.
Swift SVN r13901
We allow overloads on foo(() -> T) and foo(@auto_closure () -> T) in Sema, so they need distinct manglings. Fixes <rdar://problem/16045566>.
Swift SVN r13856
Pass the context generic params for a reabstraction thunk down to getOrCreateReabstractionThunk from the enclosing function, where it can either use them to define a new thunk or ignore them if it has an equivalent thunk already. Tweak the mangling of reabstraction thunks to use the generic signature with decontextualized "from" and "to" types instead of the generic param list.
Swift SVN r13763
Make up manglings for generic signatures and their dependent GenericTypeParamTypes and DependentMemberTypes, as well as the generic signature of a GenericFunctionType or SILFunctionType. Use these to build the mangling for a SILFunctionType from its interface types.
Swift SVN r13537
Making DynamicSelf its own special type node makes it easier to opt-in
to the behavior we want rather than opting out of the behavior we
don't want. Some things already work better with this representation,
such as mangling and overriding; others are more broken, such as the
handling of DynamicSelf within generic classes and the lookup of the
DynamicSelf type.
Swift SVN r13141
- Int and UInt are now struct types backed by Builtin.Word. Previously they
were typealiases for Int64; Int and Int64 are now distinct types.
- Mangled names 'i' and 'u' are now Int and UInt. Int64 is mangled longhand.
- Word is a typealias for Int. It is expected to go away in the future.
- Builtin.Word is unchanged.
- CLong and CUnsignedLong are typealiases for Int and UInt.
- FixedPoint.swift is now FixedPoint32.swift and FixedPoint64.swift.
Reunifying these requires better builtins, especially for checked
conversions (rdar://15472770).
- Updated many tests, mostly because Int is no longer spelled Int64 in sil.
- One check was removed from test decl/operator/operators.swift
because it changed behavior when Int became a non-typealias
type (rdar://15934688).
Swift SVN r13109
type, so we emit them. Add mangler (and demangler) support for these.
Enhance our testcase to check to make sure that stores within these
specifiers are direct, they don't cause recursive infinite loops.
John, I picked w/W for the mangling letters, let me know if this is ok.
Swift SVN r13050
When we're using Objective-C's memory allocation, emit .cxx_construct
methods whenever we have instance variables with in-class
initializers. Presently, these methods are just empty stubs.
Swift SVN r12211
The Objective-C runtime executes the .cxx_destruct method after the
last -dealloc has executed when destroying an object, allowing the
instance variables to remain live even after the subclass's
destructor/-dealloc has executed, which is important for memory
safety. This fixes the majority of <rdar://problem/15136592>.
Note that IRGenModule::getAddrOfIVarDestroyer() contains an egregious
hack to find the ivar destructor SIL function via a linear
search. We need a better way to find SIL functions that we know exist,
because LinkEntity does not suffice.
Swift SVN r12206
This allows them to appear in argument lists of functions, enabling behavior
like this:
func test_arguments(a : Int, var b : Int, let c : Int) {
a = 1 // ok (for now).
b = 2 // ok.
c = 3 // expected-error {{cannot assign to the result of this expression}}
}
Swift SVN r11746
with qualifiers on it, we have two distinct types:
- LValueType(T) aka @lvalue T, which is used for mutable values on the LHS of an
assignment in the typechecker.
- InOutType(T) aka @inout T, which is used for @inout arguments, and the implicit
@inout self argument of mutable methods on value types. This type is also used
at the SIL level for address types.
While I detangled a number of cases that were checking for LValueType (without checking
qualifiers) and only meant @inout or @lvalue, there is more to be done here. Notably,
getRValueType() still strips @inout, which is totally and unbearably wrong.
Swift SVN r11727
We'll need to perform name lookup based on the file-level
DeclContext*, so the module no longer suffices. No functionality
change here yet.
Swift SVN r11523
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
