These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
This is mostly useful for the standard library, whose name is going to
change to "Swift" soon. (See <rdar://problem/15972383>.) But it's good DRY.
Swift SVN r13758
Also, disallow creating Modules and FileUnits on the stack. They must always
live as long as the ASTContext.
<rdar://problem/15596964>
Swift SVN r13671
Because this is useful in testing, I've left in a frontend option
-enable-source-import for both swift and swift-ide-test that sidesteps the
module restriction. Right now, though, this is the right thing to avoid
users running into strange issues when they import another file within
their module and Swift treats it as a separate module.
<rdar://problem/15937521>
Swift SVN r13248
This has the potential to significantly reduce compile times in primary file
mode: for example, compiling Song.swift from the Name That Tune example as the
primary file previously took ~2.0s with a release build on my machine; with this
change, it now only takes ~0.8s. (The old compile time was presumably dominated
the time it takes to type-check AppDelegate.swift, which is a larger file.)
Swift SVN r13140
This adds some ugliness in the current swift binary because we weren't
bothering to set a requested action before, but it keeps things simpler
elsewhere. (Thanks, Connor.)
Swift SVN r13067
This necessitated adding a new function to validate a serialized AST, so
that we can get the same information that used to be extracted from the
section header.
For now, we'll continue accepting the wrapped ASTs as well, since we
haven't changed the existing debug info generator.
Swift SVN r12922
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
Hardcoding a path to a particular SDK is definitely the wrong thing to do.
Let's see how far we can get without setting a default SDK.
See discussion in <rdar://problem/14395800>
Swift SVN r12414
During CompilerInstance::performParse(), set CompilerInstance::PrimarySourceFile if we create a SourceFile from a buffer whose ID matches the PrimaryBufferID.
This allows clients of CompilerInstance to get a SourceFile for the user-specified primary input.
Swift SVN r12156
This matches how we will handle primary inputs.
This also fixes an issue where a file named main.swift may not be chosen as the main file if there were multiple inputs and it was replaced by an input buffer.
Swift SVN r12154
Also updated findModule() in SourceLoader.cpp and SerializedModuleLoader.cpp to get the ImportSearchPaths from the ASTContext’s SearchPathOpts, instead of directly from the ASTContext.
Swift SVN r11214
Added a new SearchPathOptions class to swiftAST, which will contain options like import search paths and the SDK path.
Moved the RuntimeIncludePath from CompilerInvocation into SearchPathOptions. For now, at least, the RuntimeIncludePath is handled separately from other ImportSearchPaths, since we can’t yet guarantee that RuntimeIncludePath is set up before we parse the ImportSearchPaths.
Added a SearchPathOptions member to ASTContext.
Updated findModule() in SourceLoader.cpp and SerializedModuleLoader.cpp to check RuntimeIncludePath after everything else if no module was found. (This matches existing behavior, which had RuntimeIncludedPath at the end of ImportSearchPaths.)
Swift SVN r11213
Each loaded file gets added to the main module, rather than being a standalone
separate module. In theory, this will be used to assemble several partial
ASTs into a complete module. In practice, there's still a ways to go...but
this can already round-trip a single module file.
This also factors out the FileUnit-creating part of SerializedModuleLoader,
which should help clients like SourceKit that don't need to search for a
swiftmodule file associated with a particular import.
Swift SVN r10952
'doIt' is semantically meaningless, and doesn't mention the fact that nothing
has actually been compiled yet (to SIL, to IR, or to machine code).
'performParse' matches the compiler flag -parse, which stops after
type-checking.
No functionality change.
Swift SVN r10951
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
Otherwise, we'll try to type-check bits of the main source file before we've
even looked at any of the supporting files.
This affects implicit multi-file mode, where "main.swift" is assumed to be
the main source file and all others are treated as library files. (See r9890.)
<rdar://problem/15526743>
Swift SVN r10795
Also remove the SourceLoc parameter from addNewSourceBuffer(). In llvm::SourceMgr
it is used to indicate textual inclusion, which we don't have in swift.
Swift SVN r10014
New rules for the driver (first match):
1. -repl: no input files allowed
2. -parse-sil: one input file allowed
3. -parse-as-library: any number of input files, all treated as Library
4. one input, extension is .sil: treated as SIL
5. one input: treated as Main
6. many inputs: treated as Library by default; "main.swift" is treated as Main
If we want more control here we can also add a -main-file option to explicitly
call out the main source file, but this at least unblocks building an entire
app target (like ListMaker) with a single Swift invocation.
Swift SVN r9890
Ideally this wouldn't be necessary, but the type substitution APIs required by generic specialization and SIL verification currently require a Module* pointer, and it's obnoxious to have to pass it down separately everywhere it's needed. Longer-term the reliance on Modules for type substitution might be able to go away.
Swift SVN r9866
There is still plenty of fallout to get everything fully correct, but
right now we can build the standard library and run all the tests in
multiple-file mode.
Swift SVN r9673
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
Being able to pass -l to the driver isn't so interesting, and it's an
extra field that lives on TranslationUnit for no reason. Just remove it.
This doesn't interfere with autolinking, i.e. inferring -l flags based on
imported modules.
Swift SVN r9241
docs/Resilience.rst describes the notion of a resilience component:
if the current source file is in the same component as a module being
used, it can use fragile access for everything in the other module,
with the assumption that everything in a component will always be
recompiled together.
However, nothing is actually using this today, and the interface we
have is probably not what we'll want in 2.0, when we actually implement
resilience.
Swift SVN r9174
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
Right now this is just an extra layer of indirection for the decls,
operators, and imports in a TU, but it's the first step towards compiling
multiple source files at once without pretending they're all in a single
file. This is important for the "implicit visibility" feature, where
declarations from other source files in the same module are accessible
from the file currently being compiled.
Swift SVN r9072
This reverts r8624 and compensates by passing the TU to the SILModule printer when needed.
This addresses concerns that Jordan and Sean had raised.
Swift SVN r8678
