Separate InputFileKind from SourceFileKind, FrontendOptions will now use
InputFileKind, while Module will use SourceFileKind.
This is in preparation for adding an input file kind for LLVM IR.
rdar://19048891
Swift SVN r25555
This is mainly for the debugger's use, to set up CompilerInvocations that
match how a particular app was compiled in certain important ways. Today
that's the target (which is also in the binary), the SDK path (which in
the long run should probably be an SDK name), and any random -Xcc options
we need to pass (which we should probably attempt to minimize).
Because there's only one target and SDK per context, and because -Xcc
options can easily conflict, this is only intended to be used once per
CompilerInvocation.
Note that search paths are not covered by this; they are already being
added at the time the module is loaded. See r24545.
Completes rdar://problem/17670778.
Swift SVN r25227
This implicitly adds the named module as an import of every source file
in the module being compiled. This is not intended to be used generally,
but will be useful for playgrounds.
rdar://problem/19605934
Swift SVN r24905
There's also a testing option, -serialize-debugging-options, to force this
extra info to be serialized even for library targets. In the long run we'll
probably write out this information for all targets, but strip it out of
the "public module" when a framework is built. (That way it ends up in the
debug info's copy of the module.)
Incidentally, this commit includes the ability to add search paths to the
Clang importer on the fly, which is most of rdar://problem/16347147.
Unfortunately there's no centralized way to add search paths to both Clang
/and/ Swift at the moment.
Part of rdar://problem/17670778
Swift SVN r24545
This has been long in coming. We always had it in IRGenOpts (in string form).
We had the version number in LangOpts for availability purposes. We had to
pass IRGenOpts to the ClangImporter to actually create the right target.
Some of our semantic checks tested the current OS by looking at the "os"
target configuration! And we're about to need to serialize the target for
debugging purposes.
Swift SVN r24468
This refactoring is groundwork for saving the cross-module dependencies
in the swiftdeps files as well, so that we know to rebuild files if an
outside file changes (such as a bridging header, another framework's
headers, or another framework's swiftmodule).
Part of rdar://problem/19270920
Swift SVN r24258
This is a hidden frontend-only option intended for debugging purposes,
mainly for identifying where in a file the type checker is spending most
of its time. Use with "sort -g" to get the top problem functions.
Swift SVN r23789
This should have been done a long time ago since SILOptions are options that
should be able to effect everything SIL related. In this case I just want to
pass in a flag on the SILModule to enable +0 self. By putting it on the
SILModule I can conveniently check it in SILFunctionType without exposing any
internal state from SILFunctionType.cpp.
Swift SVN r23647
This tracks top-level qualified and unqualified lookups in the primary
source file, meaning we see all top-level names used in the file. This
is part of the intra-module dependency tracking work that can enable
incremental rebuilds.
This doesn't quite cover all of a file's dependencies. In particular, it
misses cases involving extensions defined in terms of typealiases, and
it doesn't yet track operator lookups. The whole scheme is also very
dependent on being used to track file-level dependencies; if C is a subclass
of B and B is a subclass of A, C doesn't appear to depend on A. It only
works because changing A will mark B as dirty.
Part of rdar://problem/15353101
Swift SVN r22925
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
This may be something to refactor in the future, but for now the two sets
of options need the module name for entirely different reasons.
rdar://problem/17918172, again.
Swift SVN r22150
Without this, clients that don't use a CompilerInstance (like LLDB) won't
have target configuration options available.
Also, move minimum OS checking into the driver. This makes sure the check
happens early (and only once), and in general fits the philosophy of
allowing the frontend to use configurations that might be banned for users.
<rdar://problem/17688913>
Swift SVN r20701
We do this so that the swiftmodule file contains all info necessary to
reconstruct the AST for debugging purposes. If the swiftmodule file is copied
into a dSYM bundle, it can (in theory) be used to debug a built app months
later. The header is processed with -frewrite-includes so that it includes
any non-modular content; the user will not have to recreate their project
structure and header maps to reload the AST.
There is some extra complexity here: a target with a bridging header
(such as a unit test target) may depend on another target with a bridging
header (such as an app target). This is a rare case, but one we'd like to
still keep working. However, if both bridging headers import some common.h,
we have a problem, because -frewrite-includes will lose the once-ness
of #import. Therefore, we /also/ store the path, size, and mtime of a
bridging header in the swiftmodule, and prefer to use a regular parse from
the original file if it can be located and hasn't been changed.
<rdar://problem/17688408>
Swift SVN r20128
Previously, the frontend detected that its output was being piped into the
driver and buffered, and decided that that wasn't a color-friendly output
stream. Now, the driver passes -color-diagnostics to the frontend to force
color output if the driver itself is in a color-output context.
<rdar://problem/16697713>
Swift SVN r18506
This performs very conservative dependency generation for each compile task
within a full compilation. Any source file, swiftmodule, or Objective-C
header file that is /touched/ gets added to the dependencies list, which
is written out on a per-input basis at the end of compilation.
This does /not/ handle dependencies for the aggregated swiftmodule, swiftdoc,
generated header, or linked binary. This is just the minimum needed to get
Xcode to recognize what needs to be rebuilt when a header or Swift source
file changes. We can revisit this later.
This finishes <rdar://problem/14899639> for now.
Swift SVN r18045
No options should be changed because of the absence of a flag. This is
necessary for clients like LLDB which may have an initial set of options
that differs from the usual set.
Part of <rdar://problem/16776705>
Swift SVN r17819
Parse-only is a hot path; keep the semantics for it separate from normal parsing, otherwise it is very
easy to introduce something expensive without checking for Invocation.getParseOnly().
Also cleans up a bit CompilerInstance::performParse() as well.
Swift SVN r17596
THIS IS NOT READY FOR USE YET.
The new plan for mixed-source non-framework targets is that the Swift
compiler will import an Objective-C header directly, and treat the decls
and imports in that header as explicitly visible to the entire target.
This means users don't have to modularize their headers before bringing
them into Swift.
This commit adds the option and introduces the "imported headers" module
as an implicit import for the source files being compiled. It also directs
the Clang importer to process the given header (using #import, so that it
won't somehow get included twice) and watches for any module imports that
occur as a result of reading that header.
Still to come: import of decls within the header (not within any module),
and proper serialization of cross-references to the header and its imports.
Part of <rdar://problem/16702101>
Swift SVN r17218
This option implicitly imports the Clang module with the same name as the
module being built into every source file in the module being built.
This will be used for mixed-source framework targets to give Swift code the
same implicit visibility for Objective-C decls in the same module that it
already has for other Swift decls.
<rdar://problem/16701230>
Swift SVN r17053
The driver infers the filename from the module file by replacing the extension,
and passes the explicit path to the swiftdoc file to the frontend. But there
is no option in the driver to control emission of swiftdoc (it is always
emitted, and name is always inferred from the swiftmodule name).
The swiftdoc file consists of a single table that maps USRs to {brief comment,
raw comment}. In order to look up a comment for decl we generate the USR
first. We hope that the performance hit will not be that bad, because most
declarations come from Clang. The advantage of this design is that the
swiftdoc file is not locked to the swiftmodule file, and can be updated,
replaced, and even localized.
Swift SVN r14914
"Playground Transform." This is an
instrumentation pass that adds calls to a
function called playground_log at locations of
interest. Roughly speaking, these locations are
- Initialization of variables
- Modification of variables
- Expressions returning values
- Application of mutating methods on objects
The playground transform currently only finds
modifications of variables, but the intent is to
make all of these cases work.
It is enabled by a frontend option, and can
also be invoked by calling
swift::performPlaygroundTransform(SF)
which is the way LLDB, its main client, will
use it.
The frontend option is intended for testing,
and indeed I will add tests for this
transformation in the coming week as I bring
more functionality online.
Swift SVN r14801
This was causing all the external definitions to go from SILGen through
IRGen multiple times per REPL statement. Since this only matters if we
have source modules enabled, just turn it off.
We still generate all the external definitions for every REPL /line/, which
is the cause of <rdar://problem/16164076>.
Swift SVN r14467
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
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
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
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
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
This keeps us from having to deal with fat swiftmodules for now.
In the long run we're hoping to solve this problem with build configurations,
so that a single module file can support multiple architectures.
(See <rdar://problem/15056323>)
<rdar://problem/15204953>
Swift SVN r13135
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
TargetOptions only contained the target triple, which was duplicated in
IRGenOptions. These could get out-of-sync, which would cause issues during
IRGen. Since nothing was using TargetOptions other than CompilerInvocation,
removed TargetOptions in favor of making IRGenOptions the canonical home of the
target triple.
Swift SVN r12869
This option was never honored, and the main functionality that this option
would have implemented has been subsumed by -output-file-map.
Swift SVN r12800
