-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swap order of unsafe async fn
to async unsafe fn
#61319
Conversation
cc @rust-lang/lang I don't particularly care about this either way. |
Or looking from the other side, this keeps the entire function type together on the right (and non-type modifiers on the left). |
Seems fine |
This comment has been minimized.
This comment has been minimized.
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
2ebfbb4
Compare
@bors r=cramertj rollup |
📌 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. Closes rust-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. Fixes rust-lang#3025
Change the order of
unsafe async fn
toasync 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 fn
so 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