diff options
| author | Jonathan Turner <jonathandturner@users.noreply.github.com> | 2016-11-02 15:09:41 -0400 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2016-11-02 15:09:41 -0400 |
| commit | d00e5e9343a11939c80c0ade5ca71c8dcbc31847 (patch) | |
| tree | 42ca4d28f45d12affae488f7e53a7565e7a9b313 /src/test/incremental/thinlto | |
| parent | 0ca9967af75f7a279dcf4921f119b2602b41dd71 (diff) | |
| parent | 5a2fb8806ba841c74dee49a732937a71d16caff5 (diff) | |
| download | rust-d00e5e9343a11939c80c0ade5ca71c8dcbc31847.tar.gz rust-d00e5e9343a11939c80c0ade5ca71c8dcbc31847.zip | |
Rollup merge of #37351 - Amanieu:consume, r=alexcrichton
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.
Diffstat (limited to 'src/test/incremental/thinlto')
0 files changed, 0 insertions, 0 deletions
