- **Explanation**: Adding support for `swift-frontend -print-target-info -target wasm32-unknown-emscripten`, which is required before this triple is supported in `swiftc`.
- **Scope**: Limited to Emscripten Wasm support.
- **Issues**: rdar://175887675
- **Risk**: Very low due to limited scope.
- **Testing**: Added a new case to the lit test suite.
In #88224 we moved to unversioned triples. However in using the existing
getUnversionedTriple implementation, we lost the call to
getMajorArchitectureName and just used getArchName on the triple.
On OpenBSD, the spelling is amd64. We make a number of transpositions to
use the LLVM spelling x86_64 in a number of places, but the target
triple by default uses amd64. This means that instead of having a
mismatch between versioned and unversioned triple, we have a mismatch
between architecture spellings.
Here, we call getMajorArchitectureName on OpenBSD to use the LLVM
architecture spellings in getUnversionedTriple for the platform. This is
only a problem for amd64/x86_64; there is no problem on aarch64,
which is why this wasn't spotted earlier.
Prior to this change, we used versioned triples on this platform.
However, swift-build and the planned future migrations effectively
constrain the platform to abandon this module naming scheme.
Ideally, we would look for a swiftmodule named after the versioned
triple, then fall back to the unversioned triple, or vice versa.
However, this is not straightforward to do, and/or would induce a larger
change. It transpired that it was more straightforward to just convert,
despite reservations and modules generated on earlier versions requiring
recompilation in the future. Because the install base for the platform
is likely few, tackle the work to implement the fallback later and just
get this quickly done first, especially so we can hopefully make the cut
to have this incorporated in 6.3.
As a complement to `@available(anyAppleOS ...)`, evaluate `#if os(anyAppleOS)`
to true when targeting Apple's operating systems.
Resolves rdar://172747814.
This no longer causes a regression in number of CAS instances.
Prefer llvm::cas::CASConfiguration where it used to clang::CASOption.
(cherry picked from commit 4f059033bb)
llvm::VersionTuple now also supports 5-component versions; this patch removes
the limitation of stripping the last component when converting from a
swift::version::Version to an llvm::VersionTuple. This fixes a bug in LLDB's
Swift version compatibility warning.
rdar://170181060
This complements the existing Time and Live columns which (a) measure process CPU time, not wall clock time and (b) only offer 25 microsecond level precision or worse on Windows.
Otherwise these source file objects linger in the source manager but they refer to a fully-temporary 'ASTContext' which does not exist after parsing is complete, which means they cannot be used in any way and attempting to do so would lead to a crash.
This removes the C++ interop compat version mechanism. It was added in mid-2023 and was never used. It complicates the testing story, and makes it harder to reason about the compiler's behavior. It also isn't compatible with explicit module builds.
The flag `-cxx-interoperability-mode` is preserved, so projects that use the flag will continue to build normally.
rdar://165919353
This reverts commit 4f059033bb. The change
is actually not NFC since previously, there is a cache in the
CompilerInvocation that prevents the same CAS from the same CASOptions
from being initialized multiple times, which was relied upon when
running inside sub invocation. When switching to a non-caching simple
CASOption types, it causes every single sub instance will create its own
CAS, and it can consume too many file descriptors and causing errors
during dependency scanning.
rdar://164903080
On macOS 26, malloc_zone_statistics() always returns
a malloc_statistics_t with the max_size_in_use field
set to zero. This was an intentional change, so let's
remove calls to this API.
Instead, use the proc_pid_rusage() API and return the
ri_lifetime_max_phys_footprint field of rusage_info_v4.
Finally, remove the llvm::sys::Process::GetMallocUsage()
call on other platforms altogether. It returns the
current value and not the max value, so its misleading.
The `Task` class was missing a destructor to close pipe file descriptors when
destroyed. This caused file descriptor exhaustion after ~2,187 test runs,
making tests fail with POLLNVAL errors when the system ran out of resources.
This was found with:
```
./unittests/Basic/SwiftBasicTests --gtest_filter="TaskQueueTest.*" --gtest_repeat=1000
```
On older x86_64 hardware, this isn't a problem since CET IBT hardware
support may not have been available. However, newer x86_64 hardware
supports the feature, which will lead to BTCFI failures. Therefore ensure
the same BTCFI disabling logic applies on x86_64 as well as aarch64.
Removed:
- unused `SizeStatEntry` struct and `SizeStats` vector
- unused statistics counters
- dead code from `printManglingStats()` that referenced these variables
Now that we have a per-ASTContext StaticBuildConfiguration, reimplement
(almost) everything in CompilerBuildConfiguration to sit on top of it.
Only canImport requires the full ASTContext, so that gets its own
implementation, as does one other operation that can produce an error.
Aside from more code sharing, this provides additional validation that
the StaticBuildConfiguration we build is complete and accurate.
Thread the static build configuration (formed from language options) in
to the macro plugin handler, which will serialize it for use in the
macro implementation. test this with a simple macro that checks
whether a particular custom configuration (set via `-D`) is enabled or
not.
This required some re-layering, sinking the logic for building a
StaticBuildConfiguration from language options down into a new
swiftBasicSwift library, which sits on top of the C++ swiftBasic and
provides Swift functionality for it. That can be used by the C++
swiftAST to cache the StaticBuildConfiguration on the ASTContext,
making it available for other parts of ASTGen.
Introduce the ability to form a `StaticBuildConfiguration` from
language options. Add a frontend option `-print-static-build-config`
to then print that static build configuration as JSON in a manner that
can be decoded into a `StaticBuildConfiguration`.
Most of the change here is in sinking the bridged ASTContext queries
of language options into a new BridgedLangOptions. The printing of the
static build configuration only has a LangOptions (not an ASTContext),
so this refactoring is required for printing.
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.
Max Desiatov
3405691582
Doug Gregor
Alexis Laferrière
Ben Langmuir
Allan Shortlidge
Steven Wu
Jonas Devlieghere
Adrian Prantl
Saleem Abdulrasool
Anthony Latsis
Sameer Sundresh
Ian Anderson
Artem Chikin
Egor Zhdan
Slava Pestov
Guillaume Lessard
Kuba (Brecka) Mracek
Kushal Pisavadia
Mads Odgaard
Mishal Shah
swift-ci
Owen Voorhees