When we produce a physical LValue with an abstraction difference, cap off the LValue with a logical "OrigToSubstComponent", which enacts the abstraction change on load or store, and introduces a writeback for the property when used in an @inout context.
Swift SVN r11498
(various) FunctionType::get's, ArrayType::get,
ArraySliceType::get, OptionalType::get, and a few
other places.
There is more to be done here, but this is all I plan to do
for now.
Swift SVN r11497
as values, without a box at all. This generalizes some of the
previous hacks I had for silgen'ing 'self' as a value instead of
a box, and capturing them with CaptureKind::Constant.
Swift SVN r11360
I'd like to treat protocol_method equivalently to archetype_method, but we don't have a way to "open" the implicit type variable inside the existential, so protocol_method still needs to produce a "thick" witness_method reference with the Self polymorphic binding partially applied. We can at least simplify the SIL model by saying that its result is always thick, and let the lowering of @cc(witness_method) @thick in IRGen work out how thick that actually has to be for the given function type, instead of reflecting all the special cases in SIL.
Swift SVN r11330
Clear up the last bit of wanton implicit behavior in archetype_method by having it return the witness as a thin function generic on <Self: P>. Applying the result with <Self = T> will then naturally provide the polymorphic context parameters required by the witness. Tweak the implementation of SILFunctionType::substGenericArgs to handle a substitution for the Self archetype.
Swift SVN r11316
tests to fail. Basically, in the case of an empty vtable, SILVTable::create
was allocating space for 0 entries (sensible!) but then the default ctor fires
for the 1 element declared in the class, which would write off the end of the
memory block, leading to unpleasantness in random places later.
Swift SVN r11306
Tweak the type lowering code to work when the conforming type is generic. Handle the case of an associated type with protocol requirements being witnessed by an archetype of the conforming type, which results in a null ProtocolConformance pointer in the witnessing substitution.
Swift SVN r11275
When a type conforms to a protocol that refines another protocol, emit the witness table for the base protocol, and drop a reference into the witness table for the derived protocol. Keep track of what conformances we've already emitted so we don't emit redundant witness tables when types conform redundantly to base protocols or have multiple references to a base protocol via a refinement diamond.
Swift SVN r11263
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
Remove the initialize_var instruction now that DI fully diagnoses initialization problems. Change String-to-NSString bridging to explicitly invoke String's default constructor; it was the last remaining user of initialize_var. Remove dead code to emit an implicit default constructor without a body.
Swift SVN r11066
cannot decrement a retain count when they are initializations or of trivial
types. This allows us to zap some retain/releases being emitted by silgen,
particularly when accessing self ivars.
Swift SVN r11019
is used for VarDecls that are immutable once defined. This
will eventually be used to model 'val' in SILGen, but for now
we can use it to optimize some 'self' situations.
At present, we use it for class 'self' in destructors and for
init methods of root classes. The init methods of derived
classes need to be able to mutate self when calling super.init
so they can't use this presently. I haven't gotten around to
switching general methods to use it yet.
This introduces two new regressions that don't appear in the
testsuite: we lose debug info for "self" in this case, and
we cannot close over self.
Swift SVN r10962
Allow archetype_method to look up a witness from a concrete ProtocolConformance record. This will allow generic specialization to apply to constrained generic functions independent of archetype_method devirtualization. <rdar://problem/14748543>
Swift SVN r10950
They will always return a thin function with the appropriate witness CC. The metadata pointer, if any, will be passed as part of the witness CC lowering.
Swift SVN r10923
We will generate these in SILGen when we see a NormalProtocolConformance, to provide a mapping of method requirements to witnesses for types.
Swift SVN r10900
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
Part of the FileUnit restructuring. A serialized module is now represented as
a TranslationUnit containing a single SerializedASTFile.
As part of this change, the FileUnit interface has been made virtual, rather
than switching on the Kind in every accessor. We think the operations
performed on files are sufficiently high-level that this shouldn't affect us.
A nice side effect of all this is that we now properly model the visibility
of modules imported into source files. Previously, we would always consider
the top-level imports of all files within a target, whether re-exported or
not.
We may still end up wanting to distinguish properties of a complete Swift
module file from a partial AST file, but we can do that within
SerializedModuleLoader.
Swift SVN r10832
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
