Currently only inline functions referenced from Swift source files, or
from the REPL, will get IR generated for them. Inline functions
referenced by other inline functions will require additional effort to
generate properly.
With this change we use the clang::CodeGenerator-created llvm::Module
for all IR generation in Swift. This is perhaps undesirable, but
unavoidable given the interface the public Clang APIs expose, which do
not allow for building a ModuleBuilder that borrows an existing
llvm::Module.
Also unfortunate is the hack to generate a UsedAttr for each imported
inline function, but the public Clang APIs do not provide a way to only
emit deferred decls without emitting other things (e.g. module flags
that conflict with what the Swift IRGen emits). Note that we do not do
IRGen for every inline function in the module - only the ones that the
importer pulls in, which appears to be only those transitively
referenced from Swift code.
Swift SVN r13134
Previously it would create a new module if one was not passed in. There
are no uses where we do not or cannot provide a module, so it seems
reasonable to make the interface consistently require a module.
Swift SVN r13016
Adjusted how this option is handled: it is now set in IRGenOptions. If set,
this prevents the relevant passes from being added at all, instead of making
them no-ops.
Swift SVN r13005
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
We're still synthesizing external definitions too eagerly, and things
getting pulled in only through submodules aren't getting properly autolinked.
(That is, AppKit imports <QuartzCore/CIImage.h> but doesn't think that
QuartzCore is visible, because it isn't.)
The first right answer is to detect that a part of QuartzCore is visible even
though the whole thing isn't. The second right answer is to properly handle
Clang submodules as real modules---there are a lot of rough edges there.
<rdar://problem/13140302>. The third right answer is that we shouldn't even
emit references to these symbols until the /user/ needs them.
And what I'm doing now is just to attempt to link to every module that we've
synthesized thunks for.
<rdar://problem/15754311>
Swift SVN r12031
Although Cocoa.framework re-exports AppKit, Foundation, and CoreData, an
arbitrary library does not re-export most of its imports. Normally this
would be fine, but the Clang importer can pull in types too eagerly and
then generate thunks and wrappers for things we don't care about. At least
for now, return to the behavior of autolinking /anything/ that gets visibly
imported.
<rdar://problem/15705923>
Swift SVN r11844
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
Anywhere that assumes a single input file per TU now has to do so explicitly.
Parsing still puts all files in a single SourceFile instance; that's next on
the list.
There are a lot of issues still to go, but the design is now in place.
Swift SVN r9669
This is useful in -i and REPL modes, which do not have a separate linking
step. This version of the -l flag doesn't rely on TranslationUnit. I also
cleaned up the library-loading diagnostics.
Swift SVN r9488
Once we have multiple SourceFiles in a TranslationUnit, it no longer makes
sense to say "only SILGen decls starting from element N" without specifying
which source file you mean.
Also, clarify ownership by having performSILGeneration return a unique_ptr
instead of just a bare pointer.
Swift SVN r9112
The only real change here is that module-wide IR (autolinking and ObjC
runtime flags) have been pushed up from emitTranslationUnit (now
emitSourceFile) to its only caller, performIRGeneration.
Swift SVN r9075
-disable-llvm-optzns in clang tells the frontend to do everything it would
normally do at lets say -O2, except run the actual LLVM IR passes on the
resulting IR. This is useful in the case where one wants to look at the result
of a non gauranteed SIL optimization pass at the IR level without llvm
optimizations applied.
Swift SVN r8594
...instead of just those that are re-exported. This will be used for
autolinking (and probably few other places).
As part of this, we get two name changes:
(1) Module::getReexportedModules -> getImportedModules
(2) TranslationUnit::getImportedModules -> getImports
The latter doesn't just get modules-plus-access-paths; it also includes
whether or not the import is re-exported. Mainly, though, it just didn't
seem like a good idea to overload this name when the two functions aren't
really related.
No tests yet, will come with autolinking.
Swift SVN r7487
proposal.
When compiling with debug info, build a swiftmodule that contains all the
type decls referenced by DWARF and emit it into a special __apple_swiftast
section in the .o file.
Swift SVN r7398
Dynamic forms of these methods will ultimately move to the fully general TypeInfo class, but for now I'm focusing on getting fixed-layout unions working. Set up methods on FixedTypeInfo for getting the fixed count of extra inhabitants and the spare bit mask for a type. Have the default implementation of extra inhabitants count use the spare bits. For now, only actually set spare bits for types with IR-level single scalar non-power-of-two integer representation (e.g., i1, or i21).
Swift SVN r7289
gen pass has had it disabled for some time, so snip the last few uses
in the REPL and zap it.
Goodbye old friend, you were a very useful stopgap.
Swift SVN r6885
fix the build. This isn't a proper fix (we should start putting out new attributes
on llvm::Function's, but getting the build working again seems important.
Swift SVN r6584
This unfortunately duplicates the hack of directly referencing the Clang
module loader if a cross-reference points to the current module; ideally
we'd have some kind of module chain, but I'd settle for a refactoring of
the code to share with NameBinding.
Additionally, Clang nodes are not actually validated to be from the right
module, which could be problematic for extensions or any case of actual
name collision.
Swift SVN r6519
redefinition (or linkage type) bug that causes two tests to fail. I filed
rdar://13670581 to track this and am plowing forward, since they seem minor.
Swift SVN r4761
LLVM recently changed to autodetect host features by default. Change our default to use the "generic" CPU so that we emit binaries to a portable baseline (until some time in the future when we have proper -mtune and -mattr flags).
Swift SVN r4310
Implement lowering of SIL ClosureInsts by packing the partial arguments into a heap allocation and emitting a thunk to unpack them and apply the closure function, similar to curried entry points. The test doesn't work quite yet because nested FuncDecls don't get visited anymore. I need to replace my hacked SIL path with a proper walk of the SIL module to generate functions and the AST to generate types.
Swift SVN r3817
Add a path through IRGenModule to optionally codegen FuncDecls using their corresponding SIL Functions when constructed with a SILModule. Jury-rig an IRGenSILFunction subclass of IRGenFunction that does the bare minimum necessary to compile "hello world" from SIL. There are some impedance mismatches between irgen and SIL that need to be smoothed out, particularly the AST-dependent way irgen currently handles function calls. Nonetheless, `swift -sil-i hello.swift` works!
Swift SVN r3759
It doesn't do anything but crash yet. Also add an entry point fo SILGen to Subsystems so that it can be invoked without dependency on SIL or SILGen.
Swift SVN r3738
There is no protection whatsoever if the Clang-to-Swift type
conversion produces something that Swift doesn't lower in an
ABI-compatible way. That will be dealt with later.
Swift SVN r3249
