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.
Close all the pipe file descriptors in the child process after duping
them to the standard I/O. This is not necessary but it's a good thing to
do anyway.
This is future-proofing the version part of the upcoming
feature. There currently no features that require that
but it's possible that they'd be added in the future.
OpenBSD spells the common 64-bit x86 architecture as amd64, while LLVM
defaults it to x86_64. A while back we tried to stick with the amd64
spelling, but this was difficult to make the change properly and
consistently. A while back we decided to just stick with LLVM spellings,
but there are a few minor cases missing.
This change is necessary for properly finding swiftrt.o.
The "featues" part was never actually implemented and Swift Driver
is replying on information about arguments, so instead of removing
this mode, let's scope it down to "arguments" to be deprecated in
the future.
This is a replacement for `-emit-supported-features` that prints
all of the upcoming/experimental features supported by the compiler
with some additional meta information in JSON format to stdout.
Introduce a convenience for aborting while printing a given message
to a frame of the pretty stack trace. Use this in the existing places
where we're currently doing this.
To work-around #80059, we need to stop return address signing and
opt-out of BTCFI enforcement via enabling a platform linker option.
We don't want to completely undo the BTCFI work in the rare case that
we later figure out how to properly address the above issue, or allow
users who might want to benefit from BTCFI enforcement and won't use
Concurrency. To do this, condition the existing BTCFI flag enforcement
into a configuration option that defaults to off for now.
Because the new swift-driver needs to "know" whether the frontend is
configured to opt-out or not, and since the new driver communicates with
the frontend via the target info JSON to begin with, we add a field
that emits the build flavor to signal the right behavior.
This case is currently being hit for code completion, possibly due
to an invalid ASTScope node range. Let's bail in non-asserts builds
rather than crashing when attempting to access the generated source
info.
rdar://134522702
Given we're working with CharSourceRanges, the end location is past
the end of the actual range, so when checking if e.g a function body
macro is contained within the function decl, we fail since the end
location is past the closing `}`. Check the start location instead,
which is part of the range.
