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.
The definitions of how version numbers were extracted from target
triples split between the minimum platform version and for determining
the minimum inlining version.
This resulted in inlinable and transparent functions not being imported
correctly on non-Apple platforms where the version number is retained as
part of the target triple.
Specifically, `_checkExpectedExecutor` was found in the module, but
didn't have the appropriate availability version assigned, resulting in
it failing to import and the compiler silently omitting the check in
SILGen when compiling for FreeBSD.
This patch refactors the implementation of `getMinPlatformVersion` into
a separate function that is used in both places so that they cannot get
out of sync again.
Note: This changes how Windows is handled. getMinPlatformVersion
returned an empty version number for Windows, while the availability
implementation returned the OS version number. This makes both
consistently return the OS version number.
These features are baseline features and therefore are considered to be
implicitly enabled. They don't need to be explicitly enabled or queried for in
any part of the compiler.
Initially, the compiler rejected building dependencies that contained OS
versions in an invalid range. However, this happens to be quite
disruptive, so instead allow it and request that these versions be
implicitly bumped based on what `llvm::Triple::getCanonicalVersionForOS`
computes.
resolves: rdar://153205856
The migration to `MemberImportVisibility` can be performed mechanically by
adding missing import declarations, so offer automatic migration for the
feature.
Resolves rdar://151931597.
Ideally this would also update the `--version` output to be overridden
by `SWIFT_TOOLCHAIN_VERSION`, but unfortunately various tools rely on
the current format (eg. swift-build).
`HAVE_SYS_RESOURCE_H` was removed in
https://github.com/llvm/llvm-project/pull/123288, so this header is no
longer included at this particular location on rebranch, which breaks
the Linux build, where it is not transitively included either.
Use the same condition as in the use site
(`getChildrenMaxResidentSetSize`) instead.
Also, don't wrap `HAVE_GETRUSAGE` in `defined()` in case it does get
defined to 0.
Optional language features don't have a specific "-enable-*" flag, because
they're rare and don't fit the same upcoming/experimental distinction. Add
a flag_name field to provide the flag name as well.
The name of a migratable feature might differ from the names of the
diagnostic groups containing the diagnostics that are used to drive
migration for that feature. Provide the set of diagnostic categories
that are associated with each migratable feature as part of the
supported features list.
This feature is essentially self-migrating, but fit it into the
migration flow by marking it as migratable, adding
`-strict-memory-safety:migrate`, and introducing a test.
