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
Added a new ClangImporterOptions class which wraps the ModuleCachePath and ExtraArgs for the Clang importer.
Added a new ParseClangImporterArgs static function which fills in the passed-in ClangImporterOptions.
Updated CompilerInvocation and CompilerInvocation::parseArgs() to use ClangImporterOptions and ParseClangImporterArgs, respectively.
Swift SVN r11180
Added a new static ParseLangArgs, which fills in a LangOptions object.
Also moved the handling of -debug-constraints out of the loop in CompilerInvocation::parseArgs() and into ParseLangArgs, now that it has a proper home.
Swift SVN r11172
Moved the check for unknown arguments ahead of any other attempts to handle arguments.
Added test/Frontend/unknown-arguments.swift, which tests the unknown argument handling of "swift_driver -frontend".
Swift SVN r11157
Added a new FrontendOptions class, which will eventually contain the options for controlling the behavior of the frontend. (This is similar to Clang’s FrontendOptions class.)
Moved InputFilenames, OutputFilename, ModuleName, and SerializedDiagnosticsPath from CompilerInvocation into FrontendOptions.
Split out argument parsing for options in FrontendOptions into a separate ParseFrontendArgs static function.
Swift SVN r11155
The integrated frontend already doesn't handle certain arguments which it understands (such as, for the moment, '-c'), so only emit an error in the event of an unknown option, not just unhandled options.
Swift SVN r11110
Added a test which ensures that the driver invokes the integrated frontend in a way which does not produce any errors, in order to catch mismatches between the options the driver passes to the integrated frontend and the options which the integrated frontend accepts.
Swift SVN r11105
- Added support for invoking the Swift frontend via "swift_driver -frontend".
- Added frontend_main.cpp, which implements the main entry point for the
integrated frontend. (Currently, this supports compiling an input Swift file
into an object file.)
- Removed lib/Frontend/FrontendOptions.td, and replaced its functionality with
options in include/Swift/Driver/Options.td and a new
include/Swift/Driver/FrontendOptions.td. Options supported by the frontend
are denoted by the FrontendOption flag; options which are not supported by
the driver are denoted by the NoDriverOption flag.
- Updated CompilerInvocation::parseArgs() to use the option table returned from
createDriverOptTable(), including renaming a handful of options. (-triple is
now -target, and -Xclang is now -Xcc.)
Swift SVN r11082
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
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
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
