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

== after unsafe block is not correctly recognized #67347

Open
upsuper opened this issue Dec 16, 2019 · 5 comments
Open

== after unsafe block is not correctly recognized #67347

upsuper opened this issue Dec 16, 2019 · 5 comments
Labels
A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@upsuper
Copy link
Contributor

upsuper commented Dec 16, 2019

Given the following code:

let mut a = std::mem::MaybeUninit::new(10);
unsafe { std::ptr::read(a.as_ptr()) } == 10;

Rust reports error:

error: expected expression, found `==`
 --> src/main.rs:3:43
  |
3 |     unsafe { std::ptr::read(a.as_ptr()) } == 10;
  |                                           ^^ expected expression

However, if I change == to +, Rust would instead mentions that a pair of parens should be added to wrap the block:

error: expected expression, found `+`
 --> src/main.rs:3:43
  |
3 |     unsafe { std::ptr::read(a.as_ptr()) } + 10;
  |     ------------------------------------- ^ expected expression
  |     |
  |     help: parentheses are required to parse this as an expression: `(unsafe { std::ptr::read(a.as_ptr()) })`

I guess the error message should probably be updated for the == case as well.

@hellow554
Copy link
Contributor

hellow554 commented Dec 16, 2019

- is not working as well ^^

@rustbot claim

@rustbot rustbot self-assigned this Dec 16, 2019
@hellow554

This comment has been minimized.

@rustbot rustbot removed their assignment Dec 16, 2019
@rustbot rustbot added A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 16, 2019
@rustbot rustbot self-assigned this Dec 16, 2019
@hellow554
Copy link
Contributor

hellow554 commented Dec 16, 2019

According to

pub fn can_continue_expr_unambiguously(&self) -> bool {
use AssocOp::*;
match self {
BitXor | // `{ 42 } ^ 3`
Assign | // `{ 42 } = { 42 }`
Divide | // `{ 42 } / 42`
Modulus | // `{ 42 } % 2`
ShiftRight | // `{ 42 } >> 2`
LessEqual | // `{ 42 } <= 3`
Greater | // `{ 42 } > 3`
GreaterEqual | // `{ 42 } >= 3`
AssignOp(_) | // `{ 42 } +=`
LAnd | // `{ 42 } &&foo`
As | // `{ 42 } as usize`
// Equal | // `{ 42 } == { 42 }` Accepting these here would regress incorrect
// NotEqual | // `{ 42 } != { 42 } struct literals parser recovery.
Colon => true, // `{ 42 }: usize`
_ => false,
}
}

== cannot really be used. But I guess I can fix -, |, etc.

@upsuper
Copy link
Contributor Author

upsuper commented Dec 28, 2019

I mean, yes == probably cannot be used, but the error message should be more clear just like when using +.

@JohnTitor
Copy link
Member

Triage: I'm going to release assignment due to inactivity.
@hellow554 If you're still interested in this, feel free to re-claim.
@rustbot release-assignment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants