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

Syntax error while casting implicitly returned match block within a nested scope without extra parentheses #45844

Closed
vthriller opened this issue Nov 7, 2017 · 3 comments

Comments

@vthriller
Copy link

Sounds cryptic, I know, sorry for that. Here's what's going on:

fn main() {
        let foo = 1;

        // works as expected
        let bar = match foo {
                1 => 2,
                _ => 3,
        } as u8;
        
        // error: expected expression, found keyword `as`
        let bar = {
                match foo {
                        1 => 2,
                        _ => 3,
                } as u8
        };
        
        // but this works
        let bar = {
                (match foo {
                        1 => 2,
                        _ => 3,
                }) as u8
        };
        
        // and also this
        let bar = {
                1 as u8
        };
}

Meta

rustc --version --verbose:

This is present since at least stable-1.19, but here I rustup updated just to be sure:

rustc 1.21.0 (3b72af97e 2017-10-09)
binary: rustc
commit-hash: 3b72af97e42989b2fe104d8edbaee123cdf7c58f
commit-date: 2017-10-09
host: x86_64-unknown-linux-gnu
release: 1.21.0
LLVM version: 4.0
rustc 1.23.0-nightly (bd0e45a32 2017-11-06)
binary: rustc
commit-hash: bd0e45a323f85a1940d997ac237023c00670da67
commit-date: 2017-11-06
host: x86_64-unknown-linux-gnu
release: 1.23.0-nightly
LLVM version: 4.0
@vthriller
Copy link
Author

(Moving as u8 outside the scope also works.)

vthriller added a commit to vthriller/hdd-rs that referenced this issue Nov 7, 2017
@durka
Copy link
Contributor

durka commented Nov 7, 2017

This is known and can't be fixed due to the type of parser we use. Duplicate of #13012.

@vthriller
Copy link
Author

Aight, closing this as dup then.

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

2 participants