Commit to a command line option spelling so that build systems can
start testing it. I deliberately picked one of the longer names we
were considering because we can always decide to add a shorter alias,
but can't decide a shorter name was too generic.
Like the other supplementary output flags,
-emit-parseable-module-interface-path will emit a .swiftinterface file
to a particular path, while -emit-parseable-module-interface will put
it next to the main output (the one specified with -o).
rdar://problem/43776945
This enables response files for any jobs that invoke `swift` or another
toolchain tool that goes through the same driver code path, like
`swift-autolink-extract`.
Continuing work from #18344, be more conservative about when we load
SwiftOnoneSupport. Specifically, -emit-silgen and -emit-sibgen, despite
not going through the SIL Optimizer, may silently introduce dependencies
on SwiftOnoneSupport.
Because we want to support the ability to posthumously compile SILGen
and SIBGen'd files with these implicit dependencies, and because SIL
is not yet capable of expressing the dependency itself, we must always
assume we need to load SwiftOnoneSupport.
Previously if you passed `-embed-bitcode-marker` to a command that
wasn't producing an object file, it would silently be ignored. This
change puts it inline with `-embed-bitcode` in this same case, which
generates a warning.
Previously extra linker arguments had different behavior on darwin vs
other unix platforms. On darwin the arguments passed with -Xlinker would
be passed to the linker before the default arguments, where as with the
default unix toolchain they would be passed afterwards.
There isn't really a great option for which order these should be in.
If you want to have a custom rpath that takes precedence over the
default rpaths, you want them to be passed before, but if you want to
negate a default argument you want them to come after.
This change unifies the behavior so at least you always get the same
behavior across platforms.
And change a not-testing-anything-new frontend invocation into an
only-slightly-more-useful driver invocation.
This shouldn't really affect anything, but we've seen this test fail
spuriously for a long time. Maybe this fix'll stick.
rdar://problem/42247881
This dates back to the early days when the Driver was still being
brought up, but there's no reason to put them together now.
Reorganization and elimination of redundancy only.
09b043c789 didn't do the trick, probably because some of the text is
going to stdout and some to stderr. Just don't check for warnings at
all in this test, at least for now.
rdar://problem/42271414, again.
Parse-only invocations do not support the proper creation of dependency files or reference dependency files because they have not yet run name binding. Ban these invocations by diagnostic and add a new diagnostic specifically for reference dependencies.
Turns out it's needed for normal builtins that can appear in inlinable
functions, including Objective-C's @available. Clang always links it
unconditionally, so so should Swift.
Note that this does mean you have to build compiler_rt to get a
successful test run on Apple platforms. That was always true if you
wanted the sanitizer tests to work, though.
rdar://problem/41911599
This flag is based on Clang's -fdebug-prefix-map, which lets the user remap absolute paths in debug info. This is necessary for reproducible builds and allows debugging to work on a different machine than the one that built the code when paths to the source may be different.
This was retained to help ease migration between versions of the 4.2 compiler
between when the flag was originally introduced and the full fix landed. It's
not longer needed and there's no reason to retain it in the full release.
Fixes rdar://problem/40502379.
