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.
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.
Add a -verify-debug-info option that invokes dwarfdump --verify as the last step after running dsymutil. dwarfdump is invoked with same options clang 802.0.35 uses to invoke it:
dwarfdump --verify --debug-info --eh-frame --quiet
A warning is produced if -verify-debug-info is set and no debug option is also set.
dwarfdump is failing to validate the debug info in the test verify-debug-info.swift. The failure is:
error: .debug_line[0x0000007d].row[0].file = 1 is not a valid index
https://bugs.swift.org/browse/SR-2396
Previously jobs had to grovel this information out of the raw argument
list, which dropped the types we had inferred on input files. This
makes things more consistent across the compiler, though arguably we
should be able to designate "primary" and "non-primary" inputs on a
per-action basis rather than resorting to "global" state.
Use this new information to stop passing object file inputs to the
Swift frontend, fixing rdar://problem/23213785.
The list wouldn't have to live on the Compilation, but I'm going to use
it to fix SR-280 / rdar://problem/23878192 as well.
Previously we treated this the same as the inputs to the linker, but this
was problematic for a few reasons:
- Backend jobs don't produce
- .o inputs never produce .swiftmodule files (obviously).
So now we:
- explicitly track what can produce a swiftmodule
- don't run module merging if there's nothing to merge
- allow linking without a swiftmodule even under -g
Which gets us closer to being able to run the entire test suite with -g.
rdar://problem/22332569
Swift SVN r31376
The name -gnone was chosen by analogy with -O and -Onone. Like -O/-Onone,
the last option on the command line wins.
The immediate use case for this is because we want to be able to run the
tests with -g injected into every command line, but some tests will fail
when debug info is included. Those particular tests can be explicitly marked
-gnone.
rdar://problem/18636307
Swift SVN r22777
This matches Clang's behavior, though this implementation does not check
that it's actually on a platform that uses dsymutil.
<rdar://problem/16012971>
Swift SVN r20529
Most of the tests just got moved to swiftc, but some of them were
duplicated to apply to both swiftc and swift. A handful still use the
existing 'swift' because they are for the existing '-i' syntax.
Note: this means config.swift_driver now uses the staging symlink
'swifti'. The only thing preventing us from dropping the 'i' and getting
rid of the old interface is that Xcode hasn't moved to swiftc yet
<rdar://problem/17769327>.
Swift SVN r20467
These tests currently only exercise the "swift_driver -driver-print-actions"
functionality, but at this point that is the only part of the driver which is
reasonably testable without the expectation that tests will break as output
formats change.
Swift SVN r10934
