Karoy Lorentey
Karoy Lorentey
Interesting: ``` [2/13] Compiling Atomics AtomicOptional.swift :1:10: note: in file included from :1: #include "_AtomicsShims.h" ^ C:\Users\stevapple\workspace\Using\swift-atomics\Sources\_AtomicsShims\include/_AtomicsShims.h:96:1: error: use of undeclared identifier 'memory_order_acquire' SWIFTATOMIC_THREAD_FENCE_FN(acquire) ^ C:\Users\stevapple\workspace\Using\swift-atomics\Sources\_AtomicsShims\include/_AtomicsShims.h:93:25: note: expanded from macro...
Presumably `enum memory_order` is somehow missing from stdatomic.h on this config; we'll need to take a look at the header files that apply here and see where it leads us.
Huh, it does smell like there's a compiler bug involved then. It would be useful to get symbols and/or line-level debug info for that stack trace. 🤔
I haven't immediately found docs for that -- this may be worth asking about in the [Windows section of the forums](https://forums.swift.org/c/development/windows/67). Note that the assertion could be a side effect...
The big question that needs to be answered is this: do we need to restrict `ManagedAtomic`/`UnsafeAtomic` to be only marked `Sendable` if `T` itself is also `Sendable`? For example, `SomeClass`...
Putting this back on 1.0.2 -- we'll need to decide whether this can technically go in a patch release, but I think we'll want to release this together with #41...
This is more urgent than I expected, as `UnsafeAtomic` has gained an implicit, unconditional, `Sendable` conformance in the Swift 5.5 release. The implicit conformance isn't right, and the longer we...
Filed #47 to track the `UnsafeAtomic` issue, which we will need to fix as soon as possible. Fixing the `Sendable` conformance for `UnsafeAtomic` can be done in an emergency patch...
For now, I'm going to `#ifdef` out the shims when compiled outside Swift's Clang Importer.