Skip to content

[6.2] Disable layout_string_witnesses_dynamic.swift #81810

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

rjmansfield
Copy link
Contributor

  • Explanation:

Cherry-pick disabling of layout_string_witnesses_dynamic.swift

  • Scope:

Minimal risk, disabling a failing test being investigated.

  • Issues:

rdar://151476435

  • Original PRs:

#81629

  • Risk:

Failing test is blocking 6.2 nightlies

hnrklssn and others added 30 commits May 7, 2025 16:18
Swiftify cannot work in this mode. This mode has been removed entirely
in main. This takes a smaller change into the release to minimise risk.

rdar://149953125
These are discussed in the lifetime annotations pitch: swiftlang/swift-evolution#2750

Addresses rdar://150400414
These TODOs aren’t particularly actionable. What we really want is a way to define `_overrideLifetime()` in a not-unsafe way, and that will probably be a `Builtin` operation.
…-typecheck-ifconfig

[6.2][Macros] Don't include attr range when checking macro definition
swiftlang#81316)

[Swiftify] Don't use count from Span inside withUnsafeBufferPointer c… (swiftlang#81316)

Given a call like: ptr.withUnsafeBufferPointer { _ptrPtr in ... } ptr.count and _ptrPtr.count both contain the same value, but when ptr is a MutableSpan we get an error when referring to ptr inside a call to withUnsafeMutableBufferPointer, so we should use _ptrPtr.count instead.

rdar://150551109

[Swiftify] add _swiftifyOverrideLifetime for return Spans

std::span imports already have _cxxOverrideLifetime for their return
values. __counted_by needs the same, but Cxx may not be available at the
macro site, so we introduce _swiftifyOverrideLifetime in SwiftifyImport.

rdar://150569220
[6.2 🍒][Dependency Scanning] Emit a detailed error diagnostic on Clang module variant discovery
[6.2][CSFix] SE-0470: Warn about missing `@Sendable` for unapplied static …
…minosa-6.2

[6.2] Cherry-pick "Frontend: Obsolete `-fixit-all` and `-emit-fixits-path`"
…blicly-6.2

[6.2, stdlib] make _overrideLifetime() functions public
[6.2][InterfaceGen] Merge exported modules with the same public name in generated interface
…at-dep-to-distributed-and-synchronization-6.2

6.2: CMake: add explicit dependency to `_Builtin_float` to targets...
…d, use merge isolation region to tie self and the block storage into the same region.

This is an extension of a similar problem that I had fixed earlier where due to
the usage of intermediate Sendable types we do not propagate regions correctly.

The previous issue I fixed was that we were not properly tieing the result of a
foreign async completion handler to the block storage since we used an
intervening UnsafeContinuation (which is Sendable) to propagate the result into
the block storage. I fixed this by changing SILGen to insert a
merge_isolation_region that explicitly ties the result to the block storage.

This new issue is that the block that we create and then pass as the completion
handler is an @sendable block. Thus when we call the actual objc_method, the
block storage and self are not viewed as being in the same region. In this PR, I
change it so that we add a merge_isolation_region from self onto the block
storage.

The end result of this is that we have that self, the result of the call, and
the block storage are all in the same region meaning that we properly diagnose
that returning an NSObject from the imported Objective-C function is task
isolated and thus we cannot return it as a sending result.

rdar://131422332
(cherry picked from commit 227ab37)
rdar://150722907

The original handling was a workaround before LLVM added the fneg operation. Now that it has it, we should use it.
…h is on.

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 0f2b047)
This is basically the same as the one for Linux, but it would be
somewhat awkward to add the platform conditional on a file named for
Linux when OpenBSD is not Linux.

Important note: if Dispatch is disabled, then this will cause a
compilation error (probably not just for OpenBSD either), because
PlatformExecutorFactory is both defined in PlatformExecutorNone.swift
and PlatformExecutor<...>.swift in this case.

Because this only bites OpenBSD bootstrap builds, and since OpenBSD
support has been upstreamed to Dispatch, default to the Dispatch
implementation for now to get this in, and we'll refactor in a different
pr.
…#81320)

This prevents errors when compiling for older targets using a newer
compiler.

rdar://150740330
(cherry picked from commit 59d7d31)
The decl checker was effectively not being run on these because we weren’t typechecking the PBD and typechecking the VarDecl itself is basically a no-op.
Macro expansions are now treated like a part of the source file they belong to, for purposes of the “second declaration is the one that’s diagnosed” rule. This helps stabilize a behavior that was easy to perturb.
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.
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.
It’s not clear how `@abi` would apply to the auxiliary decl used for `lazy`.
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.
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.
When a language feature is used inside an `@abi` attribute, we should behave as though it was used on its counterpart. This was already half-implemented—we ensured the counterpart would use the feature—but we didn’t make the ABI decl aware that the counterpart was its parent for feature detection purposes. As a result, we would print `#if` inside the `@abi` attribute, which isn’t valid.
Additional tests for the previous commit “Diagnose CustomAttrs as needed in `@abi`”.
Additional tests for the previous commit “[Legacy parser] No freestanding macros in `@abi`”.
@AnthonyLatsis
Copy link
Collaborator

@rjmansfield FYI you can change the base branch of an open PR by clicking Edit next to the title.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.