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)
Also, make it more tolerant to instructions and builtins, which are not explicitly handled.
This avoids crashes when new instructions are added. We got lucky that this didn't happen so far.
Previously there was still a sneaky hop which caused ordering issues.
This introduced a specific test startSynchronously_order which checks
that the task enqueues indeed are "immediate" and cleans up how we
handle this.
This also prepares for the being discussed in SE review direction of
this API that it SHOULD be ALLOWED to actually hop and NOT be
synchronous at all IF the isolation is specified on the closure and is
DIFFERENT than the callers dynamic isolation.
This effectively implements "synchronously run right now if dynamically
on the exact isolation as requested by the closure; otherwise enqueue
the task as usual".
resolves rdar://149284186
cc @drexin
(cherry picked from commit a24a28c217)
When defaulting to main-actor isolation, types that have synthesized
conformances (e.g., for Equatable, Hashable, Codable) were getting
nonisolated members by default. That would cause compiler errors
because the conformances themselves defaulted to main-actor isolation
when their types were.
Be careful to only mark these members as 'nonisolated' when it makes
sense, and leave them to get the isolation of their enclosing type
when the conformance might have isolation. This ensures that one can
use synthesis of these protocols along with default main-actor mode.
There is a one-off trick here to force the synthesized CodingKeys to
be nonisolated, because the CodingKey protocol requires Sendable.
We'll separately consider whether to generalize this rule.
More of rdar://150691429.
When we discover a textual module dependency which is a module which was not originally built from source using C++ interop (specifying '-formal-cxx-interoperability-mode=off'), avoid looking up the C++ standard library Swift overlay for it. This is required for the case of the 'Darwin' module, for example, which includes headers which map to C++ stdlib headers when the compiler is operating in C++ interop mode, but the C++ standard library Swift overlay module itself depends on 'Darwin', which results in a cycle. To resolve such situations, we can rely on the fact that Swift textual interfaces of modules which were not built with C++ interop must be able to build without importing the C++ standard library Swift overlay, so we avoid specifying it as a dependency for such modules.
The primary source module, as well as Swift textual module dependencies which *were* built with C++ interop will continue getting a direct depedency of the 'CxxStdlib' Swift module.
Resolves rdar://150222155
Previously we would insert StringRefs that reference the keys in the
map, but that breaks if the invocation ever gets copied. Switch to
`std::string`.
rdar://148130166
Due to a bug in how macros on nodes imported from clang are evaluated,
their function body is not always type checked. This forces type
checking before silgen of a macro originating on a node imported from
clang, to prevent crashing in silgen.
rdar://150940383
(cherry picked from commit efd70b1f54)
Cherry-pick of #80547 for the 6.2 release branch.
---
Explanation: This cherry picks the implementation of SE-0477 to add a
string interpolation method with a `default:` parameter for optional
interpolation values.
Main Branch PR: https://github.com/swiftlang/swift/pull/80547
Risk: Low.
Reviewed By: @stephentyrone
Resolves: rdar://150865613
Testing: New tests for the string interpolations and fix-its.
This includes changing the feature name so that compilers with the experimental feature don’t accidentally pick up content that only works in the final version.
Resolves rdar://150065196.
It has indirect effects on the accessors, so it shouldn’t matter, but we can defensively redirect the query to the API counterpart anyway.
This was the last `InferredInABIAttr` attribute, so we can now remove all of the infrastructure involved in supporting attribute inference.
Inlinability doesn’t affect the mangling except in function specializations, which are applied after the fact and should never mangle in information from an ABI-only decl. That means we can simply ban these from `@abi` instead of inferring them.
Also adds some assertions to help double-check that SIL never tries to directly mangle or retrieve inlinability info from an ABI-only decl.
SwiftSyntaxParser is already doing this, and we already diagnosed it in Sema anyway, so we’re just moving that diagnostic earlier so the ASTGen testing mode is happy. Also adding compiler tests for it.
Macro-related tests are not included in this commit; they require matching swift-syntax changes which are being negotiated.
CustomAttr backs four different features, each of which requires a different behavior in `@abi`:
• Global actors: Permitted (and permitted to vary) since they can affect mangling
• Result builders: Forbidden inside an `@abi` since they have no ABI impact
• Property wrappers: Forbidden both inside an `@abi` and on a decl with an `@abi` since it’s not clear how we would apply `@abi` to the auxiliary decls
• Attached macros: Forbidden inside an `@abi` since an ABI-only decl has no body, accessors, members, peers, extensions, or (currently) conformances
Implement these behaviors (outside of `ABIDeclChecker` since they can’t be described there).
Macro-related tests are not included in this commit; they require matching swift-syntax changes which are being negotiated.
We need to use reinterpret_cast when ptrauth is enabled to ensure that any necessary auth-and-sign operations are performed.
rdar://150747009
(cherry picked from commit 0f2b047155)
With `ARCMigrate` and `arcmt-test` removed from clang in
https://github.com/llvm/llvm-project/pull/119269 and the new code
migration experience under way (see
https://github.com/swiftlang/swift-evolution/pull/2673), these options
are no longer relevant nor known to be in use. They were introduced
long ago to support fix-it application in Xcode.
For now, turn them into a no-op and emit a obsoletion warning.
(cherry picked from commit 46c394788a84d5932289c71274dd32ea2d61d9dc)
This request was looking through to the root conformance, which could
mess with the caching bits. Sink the "is nonisolated conformance" bit
down into ProtocolConformance, and have the request for a non-root
conformance be defined in terms of the request for the root
conformance.
We can always get it back from the git history.
rdar://150695113
(cherry picked from commit 9d59dbed17)
Conflicts:
include/swift/AST/DiagnosticsSema.def
include/swift/Basic/Features.def
test/abi/macOS/arm64/concurrency.swift
test/abi/macOS/x86_64/concurrency.swift
In expectation, this should never happen. Such a situation means that within the same scanning action, Clang Dependency Scanner has produced two different variants of the same module. This is not supposed to happen, but we are currently hunting down the rare cases where it does, seemingly due to differences in Clang Scanner direct by-name queries and transitive header lookup queries.
The warnings that ClangImporter emits about issues it encounters while
importing declarations from Clang modules should all belong to a diagnostic
group so that users of `-warnings-as-errors` can control their behavior using
the compiler flags introduce with SE-0443. It's especially important that these
diagnostics be controllable since they are often caused by external
dependencies and therefore the developer may not have any control over whether
they are emitted.
The `#ClangDeclarationImport` diagnostic group is intentionally broad so that
developers have a way to control all of these diagnostics with a single
`-Wwarning` flag. I fully expect that we'll introduce finer-grained diagnostic
groups for some of these diagnostics in the future, but those groups should be
hierarchically nested under `#ClangDeclarationImport`, which is supported by
SE-0443.
Resolves rdar://150524204.
