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
Upstream has renamed the DEBUG() macro to LLVM_DEBUG. This updates swift
accordingly:
$ find . -name \*.cpp -print -exec sed -i "" -E "s/ DEBUG\(/ LLVM_DEBUG(/g" {} \;
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.
IRGen can introduce calls to type metadata accessors for types that
should not be visible to the current translate, which can manifest in
linker errors within a module (for references to private types when
whole module optimization is disabled) or across modules (for
references to private/internal types in another module). Introduce a
new compiler flag `-emit-public-type-metadata-accessors` that emits
all type metadata accessors with public linkage, to work around the
problem in affected projects. This flag is intended to go away once we
have a proper solution.
This bug has been around in Swift "forever", but compiling the
overlays using -enable-resilience has exacerbated the problem and
caused regressions. This is a short-term fix to
rdar://problem/40229755 while we work on the correct long-term fix.
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.
Explicitly disable batch mode in createCompilerInvocation, since it uses
-force-single-frontend-invocation. Previously we were getting spurious
warnings. Also add a test that -disable-batch-mode will allow commands
that use -index-file to avoid the same warning, since that is likely
what they want to do as well.
rdar://39581506
When the supplementary-outputs file is written for an -index-file invocation it writes out the first input file
given in arguments instead of the input file that is provided by -index-file-path option. This then causes the frontend
index invocation to fail with an error because there is a mismatch in the primary input file and the input file that is written
in the supplementary-outputs file.
When generating a compiler invocation in driver::createCompilerInvocation()
we end up using filelists if the number of inputs is > 128 (to work around
command line arg limits). We never actually write them out though, and so
fail when parsing the frontend arguments that reference them.
As this function is called frequently by SourceKit and command line limits
aren't a concern here, this patch makes the 128 threshold value configurable
via a new -driver-filelist-threshold option. This is set to its maximum value
in driver::createCompilerInvocation() to ensure filelists aren't used. This
new option makes the existing -driver-use-filelists (that forces filelists to
be used) redundant as it's now equivalent to -driver-filelist-threshold=0.
Resolves rdar://problem/38231888
6af333f3 changed the implementation of -autolink-force-load to only
generate one symbol, but the /placement/ of that one symbol depends on
the order of input files, and -incremental supports adding a file
without rebuilding all other files. We don't have any need for these
two to play nice together right now, so just disallow it.
Previous to this change, the initial inspection of the -{enable,disable}-batch-mode
flag was made separate from the subsequent overriding by -wmo; this in turn meant
that the driver might decide it's "in batch mode" in one place (in particular,
when judging whether to ignore the -num-threads flag) and "in wmo mode" elsewhere
(when judging whether to emit one or multiple outputs, which depends on the
-num-threads flag).
Divergence between these two views caused the driver to effectively drop
the -num-threads flag even when overriding batch mode with wmo; since xcode
assumes that passing -wmo -num-threads _will_ cause multiple outputs, this
in turn caused linking to fail since the expected output files were not found.
* In full compilation '-c' with '-emit-module', output duplicated build
record file for full compilation *and* emit module ('~moduleonly') mode.
* In '-emit-module' only mode, use '~moduleonly' build record.
