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.
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.
Adds a -working-directory option which can be used to modify how
relative paths are resolved. It affects all other paths used in driver
options (controlled by a new ArgumentIsPath flag on options) as well as
the contents of output file maps and auxilliary file paths generated
implicitly by the compiler itself.
rdar://37713856
Summary:
The following two invocations of `swiftc` behave differently, despite
their only difference being the `-g` option:
```
swiftc foo.swift bar.o baz.swiftmodule -o foo
swiftc -g foo.swift bar.o baz.swiftmodule -o foo
```
The first invocation compiles `foo.swift`, links it with `bar.o`, and
passes the AST information from `baz.swiftmodule` to the linker. The
second invocation results in the following error:
```
<unknown>:0: error: cannot load module 'baz' as 'foo'
```
The source of the problem is that the driver determines whether to
generate a module based on the debug info level that has been
requested, and merges all .swiftmodule inputs if a module is being
generated.
Modify this behavior to instead pass .swiftmodule inputs directly to the
linker if our output is to be linked. This results in both the `swiftc` and
the `swiftc -g` invocations above succeeding.
Test Plan:
1. `utils/build-script --test` passes.
2. After cloning https://github.com/modocache/SR-2660 and modifying its
`build-driver.sh` to point at the local Swift source build
directory, running `build-driver.sh` succeeds, and lldb is able to
print descriptions with accurate debug info.
This brings the capability from clang to save remarks in an external YAML files.
YAML files can be viewed with tools like the opt-viewer.
Saving the remarks is activated with the new option -save-optimization-record.
Similarly to -emit-tbd, I've only added support for single-compile mode for now.
In this case the default filename is determined by
getOutputFilenameFromPathArgOrAsTopLevel, i.e. unless explicitly specified
with -save-optimization-record-path, the file is placed in the directory of the
main output file as <modulename>.opt.yaml.
Allow users to pass `.swiftmodule` files into the Swift driver when
compiling without `-g`. The `.swiftmodule` files are then passed to the
linker via `-add_ast_path` so that LLDB can access their AST
information.
This addresses one of two driver changes suggested in the comments of
https://bugs.swift.org/browse/SR-2660.
When the Swift driver is invoked with the `-emit-library` option, but
without an `-o` option that specifies the emitted library's filename,
logic in the `getOutputFilename()` function derives a filename:
`"lib" + <a plasible base name>"`, and then the value of the
`LTDL_SHLIB_EXT` macro.
There are two problems here:
1. Windows shared library file names, by convention, do not begin with "lib".
2. The `LTDL_SHLIB_EXT` macro is set by
`llvm/cmake/modules/HandleLLVMOptions.cmake`, based on
`CMAKE_SHARED_LIBRARY_SUFFIX`, a built-in CMake variable that is set
at the time LLVM is configured to be built. So, if LLVM and Swift
were built on a Linux machine, but the `swiftc` executable that was
built was then invoked to produce a shared library for a Darwin target,
the library would have a ".so" suffix, not ".dylib". (It's for this
reason that the tests for this name inference, in
`test/Driver/linker.swift`, must use a regular expression that
matches both ".dylib" and ".so", despite specifying a Darwin
`-target`.)
In order to produce conventionally correct prefixes and suffixes based
on the target, modify the `getOutputFilename()` function to take an
`llvm::Triple` argument.
