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

ICE in parser with malformed extern decl #6342

Closed
brson opened this issue May 8, 2013 · 0 comments
Closed

ICE in parser with malformed extern decl #6342

brson opened this issue May 8, 2013 · 0 comments
Labels
A-parser Area: The parsing of Rust source code to an AST E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@brson
Copy link
Contributor

brson commented May 8, 2013

fn main() {
}

extern {
    what();
}
rust: task failed at 'assertion failed: *self.token == token::RBRACE', /home/brian/dev/rust/src/libsyntax/parse/parser.rs:3711
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug
note: try running with RUST_LOG=rustc=1,::rt::backtrace to get further details and report the results to github.com/mozilla/rust/issues
rust: task failed at 'explicit failure', /home/brian/dev/rust/src/librustc/rustc.rc:350
rust: domain main @0x2033410 root task failed
@yjh0502 yjh0502 mentioned this issue May 22, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 8, 2021
Lint: filter(Option::is_some).map(Option::unwrap)

Fixes rust-lang#6061

*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog:
* add new lint for filter(Option::is_some).map(Option::unwrap)

First Rust PR, so I'm sure I've violated some idioms. Happy to change anything.

I'm getting one test failure locally -- a stderr diff for `compile_test`. I'm having a hard time seeing how I could be causing it, so I'm tentatively opening this in the hopes that it's an artifact of my local setup against `rustc`. Hoping it can at least still be reviewed in the meantime.

I'm gathering that since this is a method lint, and `.filter(...).map(...)` is already checked, the means of implementation needs to be a little different, so I didn't exactly follow the setup boilerplate. My way of checking for method calls seems a little too direct (ie, "is the second element of the expression literally the path for `Option::is_some`?"), but it seems like that's how some other lints work, so I went with it. I'm assuming we're not concerned about, eg, closures that just end up equivalent to `Option::is_some` by eta reduction.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parser Area: The parsing of Rust source code to an AST E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

No branches or pull requests

1 participant