Add a new -ignore-spi-group-new-api flag that selectively suppresses
"new API without '@available'" diagnostics for specified SPI groups
while still reporting ABI-breaking changes.
rdar://167702700
This new OSSA invariant simplifies many optimizations because they don't have to take care of the corner case of incomplete lifetimes in dead-end blocks.
The implementation basically consists of these changes:
* add the lifetime completion utility
* add a flag in SILFunction which tells optimization that they need to run the lifetime completion utility
* let all optimizations complete lifetimes if necessary
* enable the ownership verifier to check complete lifetimes
Swift host libraries should depend on LLVM libraries as part of the
`LLVM_LINK_COMPONENTS` argument so the dependency graph can be properly
set up. This is a problem when building LLVM as a DLL on Windows as
Swift targets should depend on the LLVM DLL.
Bug: #85241
Some Darwin platforms like DriverKit use a system prefix on all of their search paths. Even though DriverKit isn't supported, add support to get the system prefix from SDKSettings when constructing the default search paths.
This requires the DarwinSDKInfo to be gotten earlier in CompilerInvocation, pass that down to ASTContext through CompilerInstance.
-platform-availability-inheritance-map-path is no longer needed to support visionOS in tests, remove that and its supporting code that gets an alternative DarwinSDKInfo.
rdar://166277280
This is to keep clang module cache hashes consistent throughout the
build and avoid inconsistent hash errors due to the CodeGenOpts
changing at the IRGen phase in the middle of a build.
https://github.com/swiftlang/swift/issues/86116
All linux and Android CI show this being repeated many times, eg when
[building the Docc binary on the linux
CI](https://ci.swift.org/job/swift-PR-Linux-smoke-test/24247/consoleText):
```
"/home/build-user/build/buildbot_linux/unified-swiftpm-build-linux-x86_64/x86_64-unknown-linux-gnu/release/docc.build/main.swift.o" "-lswiftObservation" ... repeated many times ... "-lswiftObservation" "-lswiftCore"
```
Ensure that we nativize the path and consider only the filename starting
prefix to account for file suffixes (e.g. `.exe` on Windows). This
ensures that we properly support other platforms.
MCCAS wasn't setup correctly when using parallel WMO. Make sure the
CAS ObjectStore and ResultCallbacks are passed to LLVM backend when
using parallel WMO.
rdar://164409895
-iframework is a holdover from when swift-api-digester was an LLVM tool. Now that everything has switched over to -Fsystem, -iframework can be removed.
rdar://153665579
Currently symbol graphs are always written in files that contain 1 to 2
module names. It's possible for Swift module names to be very long, so
combining 2 of them in file name like `module1@module2...` in the same
path component means the name can be too long for some file systems. The
new option `-symbol-graph-shorten-output-names` changes the symbol graph
output files to use a MD5 hash of the module name(s) as the filename and
outputs an additional JSON file with the original names mapped to the
real filename. The module names JSON can be used to construct a VFS
overlay with the original naming scheme.
fix#83723
I considered using vfsoverlay, which seems like a viable solution, but
the vfsoverlay options don't seem to apply to any of the outputs from
the compiler. When I set an overlay to remap the symbol graph file
outputs, the remapped external paths aren't used so the root problem of
too long file names remains.
This pass has been disabled since a very long time (because it's terrible for code size).
It does not work for OSSA. Therefore it cannot be enabled anymore (as is) once we have OSSA throughout the pipeline.
So it's time to completely remove it.
We now have several new runtime libraries in the toolchain but they are
not listed in the autolink deduplication list. This can lead to an excessive
memory footprint when linking on platforms that use autolink-extract.
See https://github.com/swiftlang/swift/issues/58380
Specifically, we ignore the -Xllvm bit and put the option into
FrontendOptions.LLVMArgs so that parts of CompilerInvocation that assumes that
-Xllvm flags will be placed there are actually there. We still pass through the
argument to llvm::cl so it gets set that way as well.
With some changes that I am making, we will no longer need this flag at the SIL
level, so we can just make it an IRGen flag (which it really should have been
in the first place).
Specifically, I renamed the old llvm-as which printed with optimization as
llvm-as-opt and made llvm-as just test IRGen. That is really the true reason
that I created this utility many years ago: to test how IRGen lowers specific
SIL instruction sequences. How LLVM optimizes such sequences once lowered is a
different problem. I updated the one test that used sil-llvm-gen and required
optimizations to use llvm-as-opt so that the tests output did not change.
Replace the one-off compiler flag for Library Evolution with an
optional language feature. This makes the
`hasFeature(LibraryEvolution)` check work in an `#if`, and is
otherwise just cleanup.
Tracked by rdar://161125572.
This does not enable it by default. Use either of the flags:
```
-enable-copy-propagation
-enable-copy-propagation=always
```
to enable it in -Onone. The previous frontend flag
`-enable-copy-propagation=true` has been renamed to
`-enable-copy-propagation=optimizing`, which is currently default.
rdar://107610971
If these programs crash, we want them to print the Swift bug report
message, not the default LLVM one, which leads to
https://github.com/llvm/llvm-project/issues.
While here, hoist the setting of the bug report message to the
START_PROGRAM macro so that we don't forget to set it in the future.
Infer the `-target` argument to `swift-synthesize-interface` to be the host
triple when unspecified instead of emitting an error.
Resolves rdar://156353450.
