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

Document that leading blocks are never expressions #13012

Closed
comex opened this issue Mar 19, 2014 · 8 comments
Closed

Document that leading blocks are never expressions #13012

comex opened this issue Mar 19, 2014 · 8 comments

Comments

@comex
Copy link
Contributor

comex commented Mar 19, 2014

Updated description

The fact that leading blocks are never expressions needs to be documented in the language reference both in the grammar section and likely elsewhere to make it known

Original description

Can't use operators on unsafe { }

/tmp/test.rs:2:18: 2:19 error: unexpected token: `+`
/tmp/test.rs:2     unsafe { 1 } + 1;
                                ^

You need parentheses:

(unsafe { 1 }) + 1;

but it doesn't seem like that should be necessary.

@alexcrichton
Copy link
Member

This is caused by the parser parsing unsafe { ... } as a statement, and then parsing +1 as an expression (which is not a valid expression). This isn't just contained to unsafe blocks, but any block-based expression

{1} + 1
unsafe {1} + 1
if true {1} else {1} + 1

@nikomatsakis, @brson, this relates to the discussion at the work week. I think we resolved that this is working as intended, but did we intend to write up documentation for this?

@sfackler
Copy link
Member

It's also an issue with macros. I think there's already an issue for that case.

@Thiez
Copy link
Contributor

Thiez commented Mar 19, 2014

We do allow

1 + {1};
1 + unsafe{ 1 }
1 + if true {1} else {1}

It seems like the reverse should work also.

@huonw
Copy link
Member

huonw commented Mar 19, 2014

#5941 for macros.

@nikomatsakis
Copy link
Contributor

@alexcrichton this is working as intended, yes. I had no particular plan to write docs but of course that's always a nice thing to do. Not sure where that'd go, I'd assume it's just part of the language grammar, which we ought to document but as part of general work on the reference manual I guess. @Thiez no, the reverse does not work, it introduces parser ambiguities, use a parenthesis.

@alexcrichton alexcrichton changed the title Can't use operators on unsafe { } Document that leading blocks are never expressions Mar 24, 2014
@alexcrichton
Copy link
Member

Updated title/description to reflect what needs to be done.

@steveklabnik
Copy link
Member

I'm not sure how or where to appropriately document this, it seems like just straight-up invalid code.

@steveklabnik
Copy link
Member

Traige: still not clear exactly with what to do for an "I expected this to work but it doesn't," so I'm giving this a close. It's not scalable to put every kind of quesiton like this in the docs, and I don't see people asking about this very often. If it becomes a problem, we can try to figure something out eventually.

lnicola pushed a commit to lnicola/rust that referenced this issue Aug 23, 2022
This change improves the `generate_function` assist to support generating static methods/associated functions using the `Self::assoc()` syntax. Previously, one could generate a static method, but only when specifying the type name directly (like `Foo::assoc()`). After this change, `Self` is supported as well as the type name.

Fixes rust-lang#13012
lnicola pushed a commit to lnicola/rust that referenced this issue Aug 23, 2022
…soc-2, r=Veykril

feat: Generate static method using Self::assoc() syntax

This change improves the `generate_function` assist to support generating static methods/associated functions using the `Self::assoc()` syntax. Previously, one could generate a static method, but only when specifying the type name directly (like `Foo::assoc()`). After this change, `Self` is supported as well as the type name.

Fixes rust-lang#13012
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 24, 2024
[`single_match`, `single_match_else`] fix suggestion when match irrefutable

fixes rust-lang#13012

changelog:[`single_match`, `single_match_else`]: fix suggestion when `match` irrefutable
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants