When -active-platform-availability-only is specified swift-symbolgraph-extract
should only emit availability metadata for the active platform (inferred from
the -target).
Resolves rdar://174557919.
Migrate all callers of getOrCreateDatabases to either create their own CAS
instances using createDatabases() or to use the ones stored in the
CompilerInstance. Also forwards the instances into the ClangImporter and its
various clang::CompilerInstance instances.
Validated locally that this does not result in any additional calls to
createDatabases across all the swift tests. In fact, there are fewer due to an
improvement on the clange side, so I also checked that the overall reduction
doesn't hide any issues. Looking at individual cas paths that are opened, which
are per-test paths, there are none that open more than before.
Fix the debug info emitted for bridging header PCH when compilation
caching is used. This includes:
* Bridging header should have the correct dwo_name that uses CASID
* The search_path for PCH should be the cache key that can load the PCH
just like other modules.
Currently only the top level dependencies get serialized in Swift modules. In
practice this is not enough information to fully replay a module import
sequence, especially when the dependencies include binary SDK modules that were
built elsewhere. In this case we cannot follow the links to its depenencies,
since they refer to paths on a different machine or unavailable CAS. During an
EBM build, the dependency scanner writes the complete list of dependencies into
a json file called the explicit Swift module map -- including the local
locations of the dependencies of binary SDK modules. Using this LLDB can replay
a module import with 100% accuracy.
rdar://170514919
As specified in SE-0441, -language-mode should appear in help output
while -swift-version should be the hidden alias.
Related to swiftlang/swift-driver#1894
swift-synthesize-interface needs to match the safe interop wrappers
setting of the compiler invocation that built the Swift module, but
doesn't have -enable/disable-experimental-feature options. Instead of
introducing them for a single feature, which isn't even experimental,
this introduces the -disable-safe-interop-wrappers instead.
Partially revert https://github.com/swiftlang/swift/pull/86309. Keep the
SDKInfo parsing in the ASTContext separately from the search path
configuration. This allows the availablity checking to load SDKSettings
from the correct VFS.
rdar://169886913
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.
Allan Shortlidge
Keith Smiley
Ben Langmuir
Steven Wu
Adrian Prantl
Ryan Mansfield
Henrik G. Olsson
Henrik G. Olsson
Anthony Latsis
Ian Anderson
Xi Ge
Sam Pyankov
Erik Eckstein
Fabrice de Gans
Hiroshi Yamauchi
Owen Voorhees
Saleem Abdulrasool
finagolfin
Yuta Saito
Dylan Sturgeon
Michael Gottesman
Michael Gottesman
Mishal Shah
swift-ci
Doug Gregor