* Remove support for linking arclite
Darwin no longer uses arclite and it's no longer distributed
in the macOS SDKs.
This leaves the options -link-objc-runtime and -no-link-objc-runtime
in place, but strips out all the logic that actually used them.
* Remove a dead function
* Warn if `-link-objc-runtime` is used
* Update tests to not look for arclite library
* Add an explicit test for the deprecation warning
* Move the macOS-only -link-objc-runtime test to a separate test file
Various clients still use the old driver to convert a driver arguments to frontend arguments. This has to work when given new driver arguments, ie. not fail with an unknown argument error.
Move all "extra options" from the new driver into `Options.td` and mark them as new driver only.
Gather 'round to hear tell of the saga of autolinking in incremental
mode.
In the beginning, there was Swift code, and there was Objective-C code.
To make one import bind two languages, a twinned Swift module named the same as an
Objective-C module could be imported as an overlay. But all was not
well, for an overlay could be created which had no Swift content, yet
required Swift symbols. And there was much wailing and gnashing of teeth
as loaders everywhere disregarded loading these content-less Swift
libraries.
So, a solution was found - a magical symbol _swift_FORCE_LOAD_$_<MODULE>
that forced the loaders to heed the dependency on a Swift library
regardless of its content. It was a constant with common linkage, and it
was good. But, along came COFF which needed to support autolinking but
had no support for such matters. It did, however, have support for
COMDAT sections into which we placed the symbol. Immediately, a darkness
fell across the land as the windows linker loudly proclaimed it had
discovered a contradiction: "_swift_FORCE_LOAD_$_<MODULE> cannot be
a constant!", it said, gratingly, "for this value requires rebasing."
Undeterred, we switched to a function instead, and the windows linker
happily added a level of indirection to its symbol resolution procedure
and all was right with the world.
But this definition was not all right. In order to support multiple
translation units emitting it, and to prevent the linker from dead
stripping it, Weak ODR linkage was used. Weak ODR linkage has the nasty
side effect of pessimizing load times since the dynamic linker must
assume that loading a later library could produce a more definitive
definition for the symbol.
A compromise was drawn up: To keep load times low, external linkage was
used. To keep the linker from complaining about multiple strong
definitions for the same symbol, the first translation unit in the
module was nominated to recieve the magic symbol. But one final problem
remained:
Incremental builds allow for files to be added or removed during the
build procedure. The placement of the symbol was therefore dependent
entirely upon the order of files passed at the command line. This was no
good, so a decree was set forth that using -autolink-force-load and
-incremental together was a criminal offense.
So we must compromise once more: Return to a symbol with common linkage,
but only on Mach-O targets. Preserve the existing COMDAT-friendly
approach everywhere else.
This concludes our tale.
rdar://77803299
…and modify resolveFileIDConflicts() to diagnose any such violations instead of asserting.
Swift does not allow any two files in the same module to have the same filename, even if they are in different directories. However, this is enforced in the driver, so tests that invoke the frontend directly can violate it. Turns out that a couple of those snuck into the test suite at various points.
This commit updates those tests. It also causes the frontend to diagnose the duplicate filename error just as the driver would have, which should help us understand what happened more easily if this crops up again in the future.
NFC, since invoking the frontend directly is unsupported.
This doesn't yet allow including C++ headers on platforms where libc++
isn't the default; see comments in UnixToolChains.cpp for details.
However, it does, for example, allow throwing and catching exceptions in C++
code used through interop, unblocking
https://github.com/apple/swift/pull/30674/files.
The flags (-enable-experimental-cxx-interop and -experimental-cxx-stdlib) carry
"experimental" in the name to emphasize that C++ interop is still an
experimental feature.
Co-authored-by: Michael Forster <forster@google.com>
These were duplicated in 11 different files, and as they've gotten more
complex a few inconsistencies have snuck in. Sharing them should make future
changes easier and less bug-prone.
Recent-ish SDKs for Darwin platforms include an SDKSettings.json
file with version information and Catalyst SDK version mappings. Read
these (when available) and use them to pass the appropriate SDK
version down to the Darwin linker via `-platform_version`.
Finishes rdar://problem/55972144.
When enabled at the driver level, the frontends will inherit the flag. For each frontend that recieves this option, all primaries will have their reference dependencies validated.
Add support in the driver and frontend for macCatalyst target
targets and library search paths.
The compiler now adds two library search paths for overlays when compiling
for macCatalyst: one for macCatalyst libraries and one for zippered macOS
libraries. The macCatalyst path must take priority over the normal macOS path
so that in the case of 'unzippered twins' the macCatalyst library is
found instead of the macOS library.
To support 'zippered' builds, also add support for a new -target-variant
flag. For zippered libraries, the driver invocation takes both a -target and a
-target-variant flag passes them along to the frontend. We support builds both
when the target is a macOS triple and the target variant is macCatalyst and
also the 'reverse zippered' configuration where the target is macCatalyst and the
target-variant is macOS.
* Ignore -wmo when passing -dump-ast
* Cleanup on driver diagnostics
* Remove the FIXME.
* Add support for ignoring `-index-file`
* Revert unrelated formatting changes
* Revert back to only ignoring `-wmo`
Ignoring both `-wmo` and `-index-file` will be harder than just `-wmo`. This is because when calling the compiler and passing `-index-file` after `-dump-ast`, the option gets un-ignored by `Driver::buildOutputInfo`. Therefore, we will just ignore `-wmo` for now.
* Add tests, inspired by `Driver/batch_mode_with_WMO_or_index.swift`
Frontend outputs source-as-compiled, and source-ranges file with function body ranges and ranges that were unparsed in secondaries.
Driver computes diffs for each source file. If diffs are in function bodies, only recompiles that one file. Else if diffs are in what another file did not parse, then the other file need not be rebuilt.
There's no place to put the bridging header in a swiftinterface, and
they don't make sense with the intended use case of distribution.
Just disallow it up front.
rdar://problem/44113493
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.
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.
We used to assert migration scripts exist. This patch further
decouples these scripts and the compiler by treating missing scripts
as a regular compiler error.
Related: rdar://40538097
This work-around is no longer needed now that the full fix landed in
https://github.com/apple/swift/pull/16615. The argument is left with a warning
to help with migration between compilers with the work-around and compilers with
the full fix (see also rdar://problem/40502379).
Fixes rdar://problem/40476573.
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.
