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.
(cherry picked from commit 414adb55ca)
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).
(cherry picked from commit 3c098782b4)
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.
(cherry picked from commit 7f2649ff33)
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.
(cherry picked from commit abad2fae0f)
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.
(cherry picked from commit 4909b9baed)
Instead of expecting the plugin read `EOF` and exit, proactively
terminate the plugin and `wait` to reap it.
(cherry picked from commit 4a62ef86d4)
[Macros] 'close' unnecessary file descriptors in plugin process
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.
(cherry picked from commit 05948bcb93)
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.
(cherry picked from commit 18703d64d6)
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.
(cherry picked from commit 55bd906906)
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.
Check if the root node is a mapping node before iterating. This fixes a
crash when the YAML file is not the expected format.
(cherry picked from commit 56778b7209)
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.
Raw identifiers are backtick-delimited identifiers that can contain any
non-identifier character other than the backtick itself, CR, LF, or other
non-printable ASCII code units, and which are also not composed entirely
of operator characters.
We use experimental features to let people know that the construct is
subject to change and users should not rely on this unless they are
willing to rewrite the uses of this feature later. However, in compiler
generated code everything should be fair game, we will update the
compiler when these features change. This is a requirement to be able to
turn safe wrapper generation on by default.
With the acceptance of SE-0458, allow the use of unsafe expressions, the
@safe and @unsafe attributes, and the `unsafe` effect on the for..in loop
in all Swift code.
Introduce the `-strict-memory-safety` flag detailed in the proposal to
enable strict memory safety checking. This enables a new class of
feature, an optional feature (that is *not* upcoming or experimental),
and which can be detected via `hasFeature(StrictMemorySafety)`.
At the moment the only user of this method is `-interface-compiler-version`
and it's checked against major + minor only, so this is not going
to affect functionality.
In the future we should switch from `llvm::VersionTuple` to `swift::Version`
because swift tags have five components.
Resolves: rdar://140006577
Use the `clang::TargetInfo` to query the target pointer size for the
given triple. This is meant to enable us to properly determine
`CMAKE_SIZEOF_VOID_P`.
Add ability to automatically chaining the bridging headers discovered from all
dependencies module when doing swift caching build. This will eliminate all
implicit bridging header imports from the build and make the bridging header
importing behavior much more reliable, while keep the compatibility at maximum.
For example, if the current module A depends on module B and C, and both B and
C are binary modules that uses bridging header, when building module A,
dependency scanner will construct a new header that chains three bridging
headers together with the option to build a PCH from it. This will make all
importing errors more obvious while improving the performance.
* Move `AvailabilitySpec` handling logic to AST, so they can be shared
between libParse and ASTGen
* Requestify '-define-availability' arguments parsing and parse them
with 'SwiftParser' according to the 'ParserASTGen' feature flag
* Implement 'AvailableAttr' generation in ASTGen
RuntimeVersions.def.
This really *ought* to be NFC, but alas, there are two behavior changes.
The first is that arbitrary future versions (short of the special future
version of 99.99) used to be considered to be free of all deployment
issues, but are now just considered to offer the Swift release that's
attached to the last known release of the target platform. The old behavior
was fine in a sense: deployment issues require updating the compiler anyway,
so if you haven't taught the compiler that iOS 31 provides Swift 8.3, you
probably also haven't taught it about any problems that are fixed in
Swift 8.3. The only problem with this logic is that we often implement
compiler fixes for these deployment issues before that first OS actually
ships (and thus before we've settled on a release number), and so we end
up with a race where we start considering new releases to fix the issue
even without updating the release mapping. The new approach fixes this:
we say that the bug will be fixed in Swift 8.3, and for the time being,
there are simply no platforms that provide that fix yet. Later, we update
the mapping to say that iOS 31 provides it, and compilations targeting that
release will be able to take advantage.
The other issue is that we actually treated "future" releases of macOS 10.x
(starting with 10.16, which ended up being 11.0) the same way, instead of
treating them logically as intermediate between 10.15 and 11.0.
My initial attempt at this generation used a constexpr array of a struct
with a std::initializer_list of platform releases, exactly mirroring the
structure of the .def file and requiring the compiler to parse out the
bits relevant to the target dynamically. The approach I ended up with is
much better, but I was actually forced into it because MSVC miscompiled
those global "temporary" arrays --- they ended up uninitialized.
We're using C++ 14+ at least now across the project so these should not be necessary. It's also kind of wild that the definitions we had across different subsystems had different definitions.
