Prevent exhaustive matching of Ordering to allow for future extension #37351
Conversation
|
r? @sfackler (rust_highfive has picked a reviewer for you, use r? to override) |
sfackler
added
the
T-libs-api
|
If the purpose of the PR is to disallow exhaustive matching on |
|
If we were to do this now I'd prefer to instead just add something like I'd prefer to not embroil this future-proofing with contention over the consume memory ordering, so perhaps we could just do that piece? |
|
I renamed |
Amanieu
changed the title
|
Ok, starting a crater run for this. |
alexcrichton
added
the
S-waiting-on-crater
|
Crater reports shows one regression, but it looks to be suprious. @rfcbot fcp merge |
alexcrichton
removed
the
S-waiting-on-crater
|
Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 psst @alexcrichton, I wasn't able to add the |
|
@bors: r+ |
|
📌 Commit 5a2fb88 has been approved by |
Prevent exhaustive matching of Ordering to allow for future extension The C++11 atomic memory model defines a `memory_order_consume` ordering which is generally equivalent to `memory_order_acquire` but can allow better code generation by avoiding memory barrier instructions. Most compilers (including LLVM) currently do not implement this ordering directly and instead treat it identically to `memory_order_acquire`, including adding a memory barrier instruction. There is currently [work](http://open-std.org/Jtc1/sc22/wg21/docs/papers/2016/p0098r1.pdf) to support consume ordering in compilers, and it would be a shame if Rust did not support this. This PR therefore reserves a `__Nonexhaustive` variant in `Ordering` so that adding a new ordering is not a breaking change in the future. This is a [breaking-change] since it disallows exhaustive matching on `Ordering`, however a search of all Rust code on Github shows that there is no code that does this. This makes sense since `Ordering` is typically only used as a parameter to an atomic operation.
The C++11 atomic memory model defines a
memory_order_consumeordering which is generally equivalent tomemory_order_acquirebut can allow better code generation by avoiding memory barrier instructions. Most compilers (including LLVM) currently do not implement this ordering directly and instead treat it identically tomemory_order_acquire, including adding a memory barrier instruction.There is currently work to support consume ordering in compilers, and it would be a shame if Rust did not support this. This PR therefore reserves a
__Nonexhaustivevariant inOrderingso that adding a new ordering is not a breaking change in the future.This is a [breaking-change] since it disallows exhaustive matching on
Ordering, however a search of all Rust code on Github shows that there is no code that does this. This makes sense sinceOrderingis typically only used as a parameter to an atomic operation.