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.
Summary:
When the Swift driver executable was first added in
ed2038585f,
the code included a FIXME to support input types, like Clang's
`-x <language>` option. Perhaps as a first step in implementing this
functionality, it also included dead code that manipulated an input type
argument, even though the variable for storing the argument was never
written to.
Remove the unused input type code, and the FIXME. The FIXME is now
tracked with a Swift bug URL, so that a discussion on next steps can be had:
https://bugs.swift.org/browse/SR-6054
Test plan: `utils/build-script --release --test`
A post-commit reviewer on https://github.com/apple/swift/pull/10716
asked that the comments be removed. Remove them, as they're no longer
demarcating code that is internal to Apple.
This option tells the compiler where to find a profdata file. The
information in this file enables PGO. For more information about the PGO
infrastructure, look for the -profile-generate option and for the
llvm-profdata tool [1].
[1] http://llvm.org/docs/CommandGuide/llvm-profdata.html
Previously, Actions were responsible for freeing their inputs...
except for the ones that weren't. Or the ones that were supposed
to, but then they needed to share an input, so they couldn't anymore.
If this sounds ridiculous, you're right; now Actions are just
immediately allocated and owned by the Compilation.
The graph structure of the actions is still useful for some things; in
particular, "top-level" actions get to put their outputs somewhere
permanent rather than TMPDIR. But I expect these things to get cleaned
up in the future too.
