Previously if you passed `-embed-bitcode-marker` to a command that
wasn't producing an object file, it would silently be ignored. This
change puts it inline with `-embed-bitcode` in this same case, which
generates a warning.
...but don't hook it up to anything yet.
This is the very very start of the module stability / textual
interfaces feature described at
https://forums.swift.org/t/plan-for-module-stability/14551/
For now I've just made it a frontend option (not a driver option),
which is good enough for testing.
Introduces the -name-bind frontend action that is intended as an intermediary between the parse-only actions and a full typechecking pass. In this phase, module imports will be validated and resolved, making it possible to emit full make-style dependencies files among other things.
Note that all information available to a parse-only pass is available to name binding, but because it does not continue-on to typecheck input files, full semantic information is not.
This flag is based on Clang's -fdebug-prefix-map, which lets the user remap absolute paths in debug info. This is necessary for reproducible builds and allows debugging to work on a different machine than the one that built the code when paths to the source may be different.
This was retained to help ease migration between versions of the 4.2 compiler
between when the flag was originally introduced and the full fix landed. It's
not longer needed and there's no reason to retain it in the full release.
Fixes rdar://problem/40502379.
LLVM r334399 (and related Clang changes) moved clang::VersionTuple to
llvm::VersionTuple. Update Swift to match.
Patch by Jason Molenda.
rdar://problem/41025046
Shuffle the responsibility for creating the TaskQueue out of the
Compilation's internal job state object and into the driver. Expose
a builder convenience function that handles the argument parsing.
When providing the -parseable-output flag to the swift compiler, it will provide json formatted messages about tasks that run.
I added some optional usage information in form of user time, system time and maxrss to the output. This can be used by other tools using the compiler to get some insights about time and memory usage.
Since the output does not longer match processes run (in batch mode), I also added a real_pid field so the client could reason about jobs that belong together if needed.
rdar://39798231
This work-around is no longer needed now that the full fix landed in
https://github.com/apple/swift/pull/16615. The argument is left with a warning
to help with migration between compilers with the work-around and compilers with
the full fix (see also rdar://problem/40502379).
Fixes rdar://problem/40476573.
The logic in 46b8ad3 to avoid putting certain diagnostics into
serialized diagnostic files only makes sense if
1. every diagnostic emitted in file A.swift while processing a
different file B.swift would be emitted if we processed A.swift on
its own
2. we actually do process A.swift on its own in the same build,
or have previously done an incremental build and produced the same
diagnostic
But the latter isn't actually guaranteed: if one batch job exits with
a failure status, the driver will exit as well, assuming there's no
point in continuing. Fortunately, we do have a flag that overrides
this behavior, -continue-building-after-errors.
(As noted in the patch, -continue-building-after-errors isn't *exactly*
what we want. But it's conservatively correct.)
The signature here changed, but the old arguments implicitly converted
to the parameter types for the wrong overload, so we didn't notice.
Add a simple test that would have at least caught this for the driver.
