- Fix a misunderstanding I had about ownership requirements in my previous patch:
now any references to value-promoted self do a retain and use a ManagedValue,
just like the semantic load path used to. This is the change to visitLoadExpr
- Second, change argument lowering to drop the "self" argument of normal class
methods into a constant reference, instead of making a box for it. This
greatly reduces the amount of SIL generated for class methods.
The argument lowering piece is somewhat hacky because initializations really want
to be dealing with memory, but it seemed like the best approach given the current
design. Review appreciated.
Swift SVN r10984
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
get rid of the hack that used to be in IRGenDebugInfo.
This commit also adds a bunch of interesting testcases for function args.
Fixes <rdar://problem/15464454> Arguments sometimes go missing.
Swift SVN r10873
structs and enums are handled by DI. You can't assign to self in
a class ctor (not currently rejected, but presumably will be when
we have 'val').
Swift SVN r10871
- Change silgen to generate mark_unintialized so DI does its thing.
- Change Sema to not generate an init() method if some stored member has no initial value.
- Change Sema to disable its horrible horrible heuristic that scans init() bodies to try to decide whether members are initialized.
- This doesn't handle structs imported from clang yet.
Swift SVN r10841
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 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
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
enum ctors, and add minimal updates to DI to tolerate this. Doing so
exposed a bug that would cause DI to crash handling conditional
destruction of mark_unintialized (which was never possible
before since globals aren't destructed).
Swift SVN r10778
Existing uses use a "globalvar" kind. Add a new "rootinit" kind which
will be used for root initializers (i.e. init methods of structs, enums,
and root classes).
Swift SVN r10772
all we need to enable DI for enum constructors. Structs and classes are
more complex, and the diagnostic produced is not great. This resolves
rdar://14922277.
Also, now an unreachable code diagnostic (with no source location) is
produced when building the stdlib. I'll investigate.
Swift SVN r10725
a FuncDecl. This makes it much more straight-forward for SIL passes to
introduce a new one - without doing name lookup in the builtin module!
Swift SVN r10694
This is a very narrow fix for <rdar://problem/15463549>, a crash in
mangling affecting LLDB. We should, in general, provide useful
manglings for closures.
Swift SVN r10566
When assigning between physical lvalues, emit a 'copy_addr' instead of a load + assign sequence. This provides a higher-level semantic instruction to SIL passes, and also produces better code in many cases.
It unfortunately exposes another bug in DI which affects the test/IRGen/objc.swift test, which I've XFAILed until it can be fixed.
Swift SVN r10564
If a subclass overrides a declaration from an ObjC class extension, that decl won't have a vtable entry, and we shouldn't expect to override it. Fixes <rdar://problem/15282548>.
Swift SVN r10547
Route global var refs (except for those referencing top-level code vars) through the lazy-initializing global accessor functions for those globals.
Swift SVN r10519
For every global pattern binding, emit a lazy initializer token and function that initializes the global variables in that binding. For each of those vars, create an accessor that Builtin.once's the lazy initializer before producing the address. Hide this all behind a switch till the surrounding serialization and IRGen infrastructure catches up.
Swift SVN r10511
Instead of cutting corners by emitting a static property reference as a DeclRef, do the right thing and build a MemberRef on the metatype. Add the smarts to SILGen to recognize static property MemberRefs and emit global_addr instructions for (nongeneric, nondynamic) static properties.
Swift SVN r10482
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
of having to lower to an RValue.
This is valuable because we can often emit an expression to a
desired abstraction level more efficiently than just emitting
it to minimal abstraction and then generalizing.
Swift SVN r10455
- Enhance SILBuilder::emitStrongRelease to be smarter.
- Start using emitStrongRelease in type lowering, SILGen,
CapturePromotion (replacing its implementation of the
same logic), and MandatoryInlining (one more place)
- Rename the primitive createStrongRetain/ReleaseInst
instructions to lose their suffix.
- Now that createStrongRetain/ReleaseInst are not special
cases from the naming perspective, remove some special cases
from DeserializeSIL and ParseSIL.
Swift SVN r10449
They are the same as createStrongRetainInst and createStrongReleaseInst, but
peephole away FunctionRefInst. It turns out that there is only a couple
places in SILGen where this behavior is necessary, and this tramples on the
general pattern used in SILBuilder.
Swift SVN r10448
