Uh oh!
There was an error while loading. Please reload this page.
Swap order of unsafe async fn to async unsafe fn - #61319
Conversation
Uh oh!
There was an error while loading. Please reload this page.
cramertj
commented
May 29, 2019
cc @rust-lang/lang I don't particularly care about this either way. |
Uh oh!
There was an error while loading. Please reload this page.
petrochenkov
commented
May 29, 2019
Or looking from the other side, this keeps the entire function type together on the right (and non-type modifiers on the left). |
withoutboats
commented
May 30, 2019
Seems fine |
This comment has been minimized.
This comment has been minimized.
cramertj
commented
May 30, 2019
r=me with rebase and any |
We discussed this on the language team meeting and didn't find any problems with it. @nikomatsakis noted, I believe, that |
86dd88f to
2ebfbb4CompareCentril
commented
May 30, 2019
@bors r=cramertj rollup |
bors
commented
May 30, 2019
📌 Commit 2ebfbb4 has been approved by |
…amertj Swap order of `unsafe async fn` to `async unsafe fn` Change the order of `unsafe async fn` to `async unsafe fn`. I had intended to do this a while back but didn't get around to it... This should be done because: - It is the order used by `const unsafe fn` so therefore it is consistent. - This keeps all the "effect/restriction" modifiers to the left of `unsafe` (which according to some is not an effect) instead of mixing them such that we are more forward compatible with some sort of effect system. r? @cramertj
Rollup of 11 pull requests Successful merges: - #60897 (error: remove StringError from Debug output) - #61304 (Speed up Azure CI installing Windows dependencies) - #61319 (Swap order of `unsafe async fn` to `async unsafe fn`) - #61342 (Set ellipsis_inclusive_range_patterns lint to warn) - #61344 (Add regression test for const generics ICE) - #61359 (Fix links in Deref documentation) - #61363 (Stabilize iter_nth_back feature) - #61369 (Fixed lifetime misspelling) - #61372 (Migrate some books to mdbook version 0.2) - #61374 (Explicitly suggest 'type_ascription' feature) - #61382 (Fixed a typo in core::convert::AsMut) Failed merges: r? @ghost
…etrochenkov Always parse 'async unsafe fn' + properly ban in 2015 Parse `async unsafe fn` not `unsafe async fn` in implementations. We also take the opportunity to properly ban `async fn` in Rust 2015 when they are inside implementations. Closesrust-lang#62232. cc rust-lang#61319, rust-lang#62121, and rust-lang#62149. r? @petrochenkov
…tril rustdoc: Correct order of `async` and `unsafe` in `async unsafe fn`s The order was swapped in rust-lang#61319 but rustdoc was never updated to match. r? @GuillaumeGomez
3047: Update async unsafe fn ordering in parser r=matklad a=kiljacken As of rust-lang/rust#61319 the correct order for functions that are both unsafe and async is: `async unsafe fn` and not `unsafe async fn`. This commit updates the parser tests to reflect this, and corrects parsing behavior to accept the correct ordering. Fixes#3025 Co-authored-by: Emil Lauridsen <mine809@gmail.com>
As of rust-lang/rust#61319 the correct order for functions that are both unsafe and async is: `async unsafe fn` and not `unsafe async fn`. This commit updates the parser tests to reflect this, and corrects parsing behavior to accept the correct ordering. Fixesrust-lang#3025
Change the order of
unsafe async fntoasync unsafe fn.I had intended to do this a while back but didn't get around to it...
This should be done because:
const unsafe fnso therefore it is consistent.unsafe(which according to some is not an effect) instead of mixing them such that we are more forward compatible with some sort of effect system.r? @cramertj