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
- Outlaw duplicate input files, fix driver, fix tests, and add test.
- Reflect that no buffer is present without a (possibly pseudo) named file.
- Reflect fact that every input has a (possible pseudo) name.
- Break up CompilerInstance::setup.
Don't bail on dups.
Conditional conformances aren't quite ready yet for Swift 4.1, so
introduce the flag `-enable-experimental-conditional-conformances` to
enable conditional conformaces, and an error when one declares a
conditional conformance without specifying the flag.
Add this flag when building the standard library (which will vend
conditional conformances) and to all of the tests that need it.
Fixes rdar://problem/35728337.
Restructure the ELF handling to be completely agnostic to the OS.
Rather than usng the loader to query the section information, use the
linker to construct linker tables and synthetic markers for the
beginning and of the table. Save off the values of these pointers and
pass them along through the constructor to the runtime for registration.
This removes the need for the begin/end objects. Remove the special
construction of the begin/end objects through the special assembly
constructs, preferring to do this in C with a bit of inline assembly to
ensure that the section is always allocated.
Remove the special handling for the various targets, the empty object
file can be linked on all the targets.
The new object file has no requirements on the ordering. It needs to
simply be injected into the link.
Name the replacement file `swiftrt.o` mirroring `crt.o` from libc. Merge
the constructor and the definition into a single object file.
This approach is generally more portable, overall simpler to implement,
and more robust.
Thanks to Orlando Bassotto for help analyzing some of the odd behaviours
when switching over.
Otherwise, we leave optimization opportunities on the table, and in
some cases even fail to remove marker intrinsics inserted by earlier
optimization.
Background: under -embed-bitcode, compilation happens in two stages: a
"frontend" job that compiles Swift code, generates LLVM IR, optimizes
it, and then emits a .bc file; and a "backend" job that takes that
.bc, converts it to assembly, and emits an object file with the
original bitcode embedded. However, there are actually optimization
passes that run before and during that "convert to assembly" step that
were getting completely skipped.
rdar://problem/34864094
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.
