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
...and then honor them.
While here, make -l a little more flexible (see interpret_with_options test).
rdar://problem/17830826, which unblocks the LLDB feature for the same.
Swift SVN r24033
r23968 wrote out a record of which source files were included in a build,
and whether they were succesfully compiled or not...and if not, whether
they were out of date because of a cascading or non-cascading dependency.
This commit uses that information to decide what files might need to be
rebuilt even if a particular input doesn't change and doesn't appear to
have any changed dependencies. The two interesting cases are:
- A file was going to be built last time, but the build was halted
because of an error. Build it this time.
- One of the files was removed and thus we've lost a source of dependency
information; rebuild everything!
rdar://problem/19270980
Swift SVN r24018
This will make future testing easier: Xcode can add a new type to the map
to support newer compilers without breaking older compilers.
rdar://problem/19212339
Swift SVN r23974
"private" is a very overloaded term already. "Cascading" instead of
"non-private" is a bit more clear about what will happen with this sort
of lookup.
No functionality change. There are some double negatives I plan to clean
up in the next commit, but this one was supposed to be very mechanical.
Swift SVN r23969
This is important because we might get part-way through the full
compilation, overwriting swiftdeps files as we go, and then encounter an
error. We don't want to lose information about any decls that have been
removed since the previous compile, so we propagate forward the information
we already have by saving it to a "build record" file.
More simply, this is necessary to track when a file is removed from a target.
The next commit will handle reading in this file at the start of a build.
Swift SVN r23968
Previously, the driver waited for the first set of known-dirty jobs to
finish before doing /any/ dependency analysis. This was correct, but
could take a lot longer (consider waiting for one touched file to compile
and then finding out that it affects three others, when all four could
have been built in parallel). This only affects the incremental build.
Swift SVN r23967
Specifically, we care about the case where a job is run because of a private
dependency, and then a non-private dependency turns out to be dirty. In
this case, we still need to make sure to build all downstream files.
With this the driver support for private dependencies should be complete
and correct.
Swift SVN r23853
- Add flags to dependency entries in DependencyGraph.
- Don't traverse past private dependencies in markTransitive.
- Only mark dependent jobs after a build if the build was triggered
(a) explicitly (because the file is out of date), or
(b) because of a non-private dependency.
This still isn't fully correct because of new non-private dependencies
discovered /after/ building an individual file, but it's on the way there.
Solving that problem will require tracking which dependencies have already
been marked dirty (next commit).
Swift SVN r23852
- Give loadWithPath an enum result that includes "NeedsRebuilding".
This will be returned when a new dependency is discovered that
retroactively affects the graph.
- Don't clear the "provides" set for a node when it gets reloaded;
just append to it. This lets us avoid calling markTransitive twice.
- Use proper types for "depends" and "provides" entries instead of std::pair.
- Use swift::OptionSet instead of a manual bitmask.
- Use separate "depends" and "provides" callbacks when parsing dependency
files.
No expected functionality change.
Swift SVN r23851
Add -whole-module-optimization option as synonym of
-force-single-frontend-invocation (for now). Add support for
-output-file-map when using -whole-module-optimization with multiple
input files -- the key for the single output file's map is the empty string.
<rdar://problem/18603795>
Swift SVN r23625
