-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[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
rjmansfield
wants to merge
847
commits into
swiftlang:main
from
rjmansfield:disable_layout_string_witnesses_6.2
Closed
[6.2] Disable layout_string_witnesses_dynamic.swift #81810
rjmansfield
wants to merge
847
commits into
swiftlang:main
from
rjmansfield:disable_layout_string_witnesses_6.2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
Fixes rdar://150060837
…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.
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`”.
@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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick disabling of layout_string_witnesses_dynamic.swift
Minimal risk, disabling a failing test being investigated.
rdar://151476435
#81629
Failing test is blocking 6.2 nightlies
Testing:
Reviewers:
@drexin