Skip to content

Document that leading blocks are never expressions #13012

Closed
@comex

Description

@comex
Contributor

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.

Activity

alexcrichton

alexcrichton commented on Mar 19, 2014

@alexcrichton
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

sfackler commented on Mar 19, 2014

@sfackler
Member

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

Thiez

Thiez commented on Mar 19, 2014

@Thiez
Contributor

We do allow

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

It seems like the reverse should work also.

huonw

huonw commented on Mar 19, 2014

@huonw
Member

#5941 for macros.

nikomatsakis

nikomatsakis commented on Mar 24, 2014

@nikomatsakis
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.

changed the title [-]Can't use operators on unsafe { }[/-] [+]Document that leading blocks are never expressions[/+] on Mar 24, 2014
alexcrichton

alexcrichton commented on Mar 24, 2014

@alexcrichton
Member

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

steveklabnik

steveklabnik commented on Dec 8, 2014

@steveklabnik
Member

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

steveklabnik

steveklabnik commented on Feb 13, 2015

@steveklabnik
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.

added 2 commits that reference this issue on Aug 23, 2022
39d17ef

Auto merge of rust-lang#13041 - DorianListens:dscheidt/gen-fn-self-as…

2f02ea0

1 remaining item

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @steveklabnik@comex@alexcrichton@nikomatsakis@Thiez

        Issue actions

          Document that leading blocks are never expressions · Issue #13012 · rust-lang/rust