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.
Since LayoutPrespecialization has been enabled by default in all compiler
invocations for quite some time, it doesn't make sense for it to be treated as
experimental feature. Make it a baseline feature and remove all the
checks for it from the compiler.
AllowDeserializingImplementationOnly was historically added as a defensive
check against deserailzation issues introduced by @implementationOnly imports.
It's no longer specified by other tools, thus the ABI checker should drop
it as well.
rdar://153683760
Textual interfaces for 'Darwin' built with recent compilers specify that it is built witout C++ interop enabled. However, to ensure compatibility with versions of the 'Darwin' module built with older compilers, we hard-code this fact. This is required to break the module cycle that occurs when building the 'Darwin' module with C++ interop enabled, where the underlying 'Darwin' clang module depends on C++ standard library for which the compiler brings in the 'CxxStdlib' Swift overlay, which depends on 'Darwin'.
Improve diagnostics message for swift caching build by trying to emit
the diagnostics early when there is more context to differentiate the
different kind of problems.
After the improvement, CAS Error should be more closer to when there is
functional problem with the CAS, rather than mixing in other kinds of
problem (like scanning dependency failures) when operating with a CAS.
rdar://145676736
