Added -debug-assert-immediately and -debug-crash-immediately, which cause an
llvm_unreachable or LLVM_BUILTIN_TRAP to execute during argument parsing.
Added -debug-assert-after-parse and -debug-crash-after-parse, which cause an
llvm_unreachable or LLVM_BUILTIN_TRAP to execute after calling
CompilerInstance::performParse().
This fixes <rdar://problem/16013025>.
Swift SVN r13653
Prior to r13134, the modules being constructed for IRGen always used the
LLVM global context due to <rdar://problem/15283227>, but the interface
should really take this as a parameter rather than baking the behavior
into IRGen.
Swift SVN r13260
I am going to use this in a forthcoming patch which creates a special mode
called "ParanoidVerification" which runs the verifier after all passes.
"ParanoidVerification" will be by default off and will be used on the swift-fast
buildbot to help catch bugs which might be hidden by optimizations being run.
Swift SVN r13256
SILSerializeAll and EmitVerboseSIL are /not/ being moved because they are
options controlling the output, not about SILGen and SIL passes.
No functionality change.
Swift SVN r13197
Plumbing this through to the inliner necessitated the creation of a
SILOptions class (like FrontendOptions and IRGenOptions). I'll move
more things into this soon.
One change: for compatibility with the new driver, the option must be
specified as "-sil-inline-threshold 50" instead of "-sil-inline-threshold=50".
(We're really trying to be consistent about joined-equals vs. separate
in the new frontend.)
Swift SVN r13193
...and probably should not be emitted before optimization passes.
The new frontend got this wrong, and the old one pretended to allow it but
then silently didn't write a module at all.
Swift SVN r13189
Also, restructure so that the option isn't declared in a random library file.
(And do the same with "-sil-link-all".)
Part of the migration to the new driver.
Swift SVN r13184
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
Currently when compiling with debug info, the AST gets serialized into the
.o file for use by the debugger. However, when we switch to one .o file
per .swift file, this won't really make sense any more. Instead, we should
collect all the ASTs at the end of the build and merge them together, then
write /that/ into the final binary.
This commit handles writing a serialized AST with an LLDB wrapper around it,
so that we can take a merged AST, write it out in the wrapper, and splice it
into the final binary using ld's -sectcreate option.
In the long run, we probably won't need the LLDB wrapper, but for now I'm
trying to disturb as little as possible. (It looks like the layout is
broken on 32-bit platforms, though...there was a problem with 64-bit
relocations in the existing SwiftASTStreamerPass, but nothing ever tried to
/read/ the new layout in 32 bits. I'm holding off on dealing with this
right now.)
Part of <rdar://problem/15786017>
Swift SVN r12667
Updated frontend_main() and performCompile() to not reject
FrontendOptions::Immediate and instead call RunImmediately() with the correct
IRGenOptions.
Swift SVN r12522
Updated the swift_driver target so that it links against swiftImmediate and
CoreFoundation.
Updated frontend_main() and performCompile() to not reject FrontendOptions::REPL
and instead call REPLRunLoop().
Swift SVN r12520
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
Added support for the -emit-module and -module-output-path options. -emit-module
and -module-output-path function similarly to -serialize-diagnostics and
-serialized-diagnostics-path: notably, -module-output-path implies -emit-module,
but -emit-module can be passed without -module-output-path and a default path
will be determined based on other inputs.
Added support for the -module-link-name option, which specifies the name of the
library to link against when importing the generated module.
Note that support for these options is only implemented in the integrated
frontend; driver-level support for these options is forthcoming.
Swift SVN r12301
Reworked the -serialize-diagnostics option, so that it is now just a flag
indicating that the frontend should generate serialized diagnostics. The path at
which the diagnostics will be serialized is now specified by the
-serialized-diagnostics-path option, which is a frontend-only option. (The
frontend treats -serialized-diagnostics-path as implying -serialize-diagnostics.)
If -serialize-diagnostics is passed but -serialized-diagnostics-path is not
passed, the frontend will choose an output path from a few default values:
- If the frontend has a non-stdout output path, replace that path's extension
with .dia.
- If there is a primary input filename, use that input's base name as the base
name for the serialized diagnostics file.
- Otherwise, use the module name as the base name for the serialized diagnostics
file.
Added support for setting up a serialized diagnostics DiagnosticConsumer in
frontend_main() if FrontendOptions::SerializedDiagnosticsPath is non-empty.
Swift SVN r12251
MainInputFilename and OutputFilename are pulled from the FrontendOptions, while Triple is parsed directly from the ArgList.
Eventually, MainInputFilename and OutputFilename should likely be removed from IRGenOptions, in favor of the values in FrontendOptions, while Triple will be in a separate TargetOptions class.
Swift SVN r11455
Moved the responsibility for storing LinkLibraries from CompilerInvocation to the invocation’s IRGenOpts.
Moved the handling of -l and -framework into ParseIRGenArgs.
Swift SVN r11450
The integrated frontend now supports:
- Parse
- DumpParse
- DumpAST
- PrintAST
- EmitSILGen
- EmitSIL
- EmitIR
- EmitBC
- EmitAssembly
- EmitObject
Moved the code for compiling into a separate performCompile() function in frontend_main.cpp, to facilitate using early returns while still supporting the diagnostic verifier.
Added some error output for the REPL, Immediate, and EmitModuleOnly actions, as the integrated frontend does not yet support these actions.
Swift SVN r11387
Added PrintHelp and PrintHelpHidden to FrontendOptions.
Marked both -help and --help-hidden with the FrontendOption flag.
Updated ParseFrontendArgs to parse -help and --help-hidden.
Updated frontend_main() so that it prints the help for the frontend options.
Swift SVN r11320
Added a new DiagnosticOptions class to swiftBasic, and added a DiagnosticOptions member to CompilerInvocation.
Added a static ParseDiagnosticArgs function to parse diagnostic-related arguments.
Added -verify to FrontendOptions.td, and added support for parsing -verify in ParseDiagnosticArgs.
Updated frontend_main() to enable and trigger the DiagnosticVerifier when -verify is passed.
Swift SVN r11318
This works around <rdar://problem/15639860>, which covers properly handling a missing -sdk argument at either the driver or frontend level (or at both levels).
Swift SVN r11153
- 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
