Skip to content

Conversation

@Azoy
Copy link
Contributor

@Azoy Azoy commented May 18, 2024

Now that BitwiseCopyable is a thing, let's enforce that atomic representations must always be bitwise copyable. This avoids a bunch of subtle issues that can occur with @_rawLayout now like not supporting non-bitwise movable values.

Resolves rdar://128296144

@Azoy Azoy requested review from glessard and lorentey May 18, 2024 17:21
@Azoy Azoy requested a review from a team as a code owner May 18, 2024 17:21
@Azoy
Copy link
Contributor Author

Azoy commented May 18, 2024

@lorentey @glessard we should amend the bitwise copyable to have 1. Never conform 2. have AtomicRepresentable's representation conform and 3. have AtomicOptionalRepresentable's representation conform.

@Azoy
Copy link
Contributor Author

Azoy commented May 18, 2024

@swift-ci please test

@nate-chandler
Copy link
Contributor

nate-chandler commented May 18, 2024

@Azoy
Copy link
Contributor Author

Azoy commented May 19, 2024

@nate-chandler was the implementation just missed then?

@nate-chandler
Copy link
Contributor

No, conformance is inferred.

@Azoy
Copy link
Contributor Author

Azoy commented May 19, 2024

Well without the explicit conformance, the compiler complains it does not conform to AtomicRepresentable.

/Users/alejandro.alonso/Desktop/swift/swift/stdlib/public/Synchronization/AtomicRepresentable.swift:258:1: error: type 'Never' does not conform to protocol 'AtomicRepresentable'
164 |   /// The storage representation type that `Self` encodes to and decodes from
165 |   /// which is a suitable type when used in atomic operations.
166 |   associatedtype AtomicRepresentation: BitwiseCopyable
    |                  `- note: protocol requires nested type 'AtomicRepresentation'; add nested type 'AtomicRepresentation' for conformance
167 | 
168 |   /// Destroys a value of `Self` and prepares an `AtomicRepresentation` storage
    :
256 | 
257 | @available(SwiftStdlib 6.0, *)
258 | extension Never: AtomicRepresentable {
    | `- error: type 'Never' does not conform to protocol 'AtomicRepresentable'
259 |   /// The storage representation type that `Self` encodes to and decodes from
260 |   /// which is a suitable type when used in atomic operations.
261 |   @available(SwiftStdlib 6.0, *)
262 |   public typealias AtomicRepresentation = Never
    |                    `- note: possibly intended match 'Never.AtomicRepresentation' (aka 'Never') does not conform to 'BitwiseCopyable'
263 | 
264 | 

@nate-chandler
Copy link
Contributor

Thanks for bringing that to my attention.

I see that error too now, but only when building for embedded. In the Swift.swiftmodule for non-embedded macosx, various inferred conformances like UnboundedRange_ : Sendable and Never : BitwiseCopyable appear in the swiftinterface (e.g. Swift.swiftmodule/arm64-apple-macos.swiftinterface); they don't appear in the .swiftmodule (e.g. Swift.swiftmodule/arm64-apple-macos.swiftmodule). In the Swift.swiftmodule for embedded, there are no .swiftinterfaces; and the inferred conformances still don't appear in the .swiftmodule files. The result is the actual non-conformance of UnboundedRange_ to Sendable and Never to BitwiseCopyable on embedded.

I filed rdar://128358780 .

In the meantime, explicitly stating the conformance of Never to BitwiseCopyable is harmless.

@nate-chandler
Copy link
Contributor

The issue with inference in the embedded stdlib is fixed by #73756 , so stating Never's conformance explicitly should no longer be needed (though it might perhaps be desirable).

@Azoy Azoy merged commit 4221d9f into swiftlang:main May 22, 2024
@Azoy Azoy deleted the bitwisecopyable-atomic-reps branch May 22, 2024 15:19
Azoy added a commit to Azoy/swift that referenced this pull request May 28, 2024
[stdlib] Enforce that atomic representations are BitwiseCopyable
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.

3 participants