With both force-single-frontend-invocation and embed-bitcode, we create
CompileJobAction and BackendJobAction, similar to how we handle embed-bitcode
with StandarCompile.
This commit should only affect Bitcode mode.
rdar://20796819
Swift SVN r28129
and link it properly. This is needed to embed LLVM bitcode sections
in the standard library and overlays. The linker doesn't support
embedded bitcode and reexport flags (among others).
rdar://problem/20750099
Swift SVN r28052
With both emit-module and embed-bitcode, MergeModule will get the swiftmodule
inputs from CompileJobAction instead of BackendJobAction.
This commit should only affect Bitcode mode since it only touches how we handle
BackendJobAction which is used for Bitcode mode.
rdar://20678489
Swift SVN r27878
No test case; this is apparently hitting Enrico but not reproducing in
any obvious way for me. Nevertheless, it /could/ be an issue, so let's be
conservative.
rdar://problem/20402875
Swift SVN r26882
This is instead of verifying that it's 0 after running a round.
The previous way would cause it to assert if it the blocking task
was at a higher level of the stack than the current level, and
thus in a different TaskQueue. This way we just verify that
no new tasks are left over.
Swift SVN r26501
SIL seems to be doing the right thing here already, which is great!
Part of rdar://problem/17732115. We'll be able to really see this working
with the next change: allowing references to testable things when using
"@testable import".
Swift SVN r26473
- Add frontend and standard library build support for tvOS.
- Add frontend support for watchOS.
watchOS standard library builds are still disabled during SDK bring-up.
To build for TVOS, specify --tvos to build-script.
To build for watchOS, specify --watchos to build-script (not yet supported).
This patch does not include turning on full tests for TVOS or watchOS, and
will be included in a follow-up patch.
Swift SVN r26278
Together with -wmo it enables multi-threaded compilation.
I didn't want to reuse the -j option for this, because -num-threads (even if n == 1) does change the generated code.
For details see commit message of r25930.
Swift SVN r26258
Later this should be derived from the target so cross-compilation
does the right thing, but for now this at least makes it so that
it does the right thing for the non-cross-compile case.
Swift SVN r25564
With -embed-bitcode, we will invoke swift twice, once to generate the bitcode
file, the second time to perform code generation on the bitcode file.
For now, -embed-bitcode causes -incremental builds to not be incremental,
because of potential issues of mixing the two.
rdar://19048891
Swift SVN r25559
These aren't inherently incompatible, but today it would do nothing useful,
and using both flags together causes problems (see previous commit).
rdar://problem/19669432
Swift SVN r25389
This adds the -profile-coverage-mapping option to swift, and teaches
SILGenProfiling to generate mappings from source ranges to counters.
Swift SVN r25266
This adds the -profile-generate flag, which enables LLVM's
instrumentation based profiling. It implements the instrumentation
for basic control flow, such as if statements, loops, and closures.
Swift SVN r25155
If a build fails in the middle, we try to determine which other files need
to be rebuilt. However, we may not be able to do that as precisely if the
dependency graph itself is incomplete. In this case, just be conservative
and assume we need to rebuild everything. We may want to revisit this in
the future with a more-aggressive-but-still-safe bound.
This was manifesting itself as an assertion failure, trying to pull
information from the graph that wasn't there.
rdar://problem/19640006
Swift SVN r24823
Also, normalize the target triple up front, so that we're never dealing
with non-normalized triples in the driver unless explicitly asking for
the original user option.
rdar://problem/18065292
Swift SVN r24563
If certain command-line arguments change, the results of the last
compilation aren't reusable, i.e. we can't do an incremental build.
Do a full rebuild when we detect that this happens.
(Which command-line options? Conservatively assume all of them, /except/
those with the new DoesNotAffectIncrementalBuild flag in Options.td.)
Swift SVN r24385
After we've added all files that are explicitly out of date, check the set
of external dependencies in the graph and see if any of them have been
modified more recently than the oldest object file (or, if an object file
is missing, the corresponding source file; see previous commit). If so,
mark that external dependency as dirty and schedule anything touched by that.
In practice, due to the way external dependencies are collected, this will
almost always lead to a full rebuild. However, the way this is structured
is semantically correct even if that were not the case: an external
dependency is a cascading dependency like any other.
One particular point of information: normal cascading dependencies can be
discovered retroactively, i.e. after a particular source file has already
been compiled. Can that happen for external dependencies? In theory, yes,
due to the leakiness of imports within a module. (If a.swift loads a module
with an extension on String, that extension will be visible to b.swift in
the same module, even though it shouldn't be.) But that's true even if the
external dependency /hasn't/ changed. Given that it's something we consider
a flaw (if low-priority: rdar://problem/16154294), and that it would be
harmless in most actual circumstances, I don't think we should actually
force a full rebuild if one file's imports change.
This completes rdar://problem/19270920
Swift SVN r24337
This is mostly just a matter of not throwing away mtimes we were already
looking up. We can compare these values to the mtimes of cross-module
dependencies to find out what's been updated.
Part of rdar://problem/19270920
Swift SVN r24336
We don't actually check them yet, but this fits them into the same dependency
structure as intra-module dependencies.
Part of rdar://problem/19270920
Swift SVN r24335
of 'bin/swift-update' with the related frontend options.
'swift-update' will be the tool for producing diffs to update swift code to the
latest version.
Swift SVN r24287
