Skip to content
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

Merged
merged 1 commit into from
Jun 1, 2019

Conversation

Centril
Copy link
Contributor

@Centril Centril commented May 29, 2019

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 29, 2019
@cramertj
Copy link
Member

cc @rust-lang/lang

I don't particularly care about this either way.

@petrochenkov
Copy link
Contributor

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.

Or looking from the other side, this keeps the entire function type together on the right (and non-type modifiers on the left).

@withoutboats
Copy link
Contributor

Seems fine

@bors

This comment has been minimized.

@cramertj
Copy link
Member

r=me with rebase and any bump-related changes you choose to make.

@Centril Centril added I-nominated T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed I-nominated labels May 30, 2019
@Centril
Copy link
Contributor Author

Centril commented May 30, 2019

We discussed this on the language team meeting and didn't find any problems with it. @nikomatsakis noted, I believe, that const unsafe as a rationale was compelling. I'll rebase in a bit. :)

@Centril Centril force-pushed the async-unsafe-fn-order branch from 86dd88f to 2ebfbb4 Compare May 30, 2019 22:53
@Centril
Copy link
Contributor Author

Centril commented May 30, 2019

@bors r=cramertj rollup

@bors
Copy link
Contributor

bors commented May 30, 2019

📌 Commit 2ebfbb4 has been approved by cramertj

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 30, 2019
pietroalbini added a commit to pietroalbini/rust that referenced this pull request May 31, 2019
…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
bors added a commit that referenced this pull request Jun 1, 2019
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
@bors bors merged commit 2ebfbb4 into rust-lang:master Jun 1, 2019
@Centril Centril deleted the async-unsafe-fn-order branch June 1, 2019 04:43
Centril added a commit to Centril/rust that referenced this pull request Jun 30, 2019
…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
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Jan 20, 2020
…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
bors bot added a commit to rust-lang/rust-analyzer that referenced this pull request Feb 7, 2020
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>
cjhopman pushed a commit to cjhopman/rust-analyzer that referenced this pull request Apr 10, 2020
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants