ICE on invalid input: fn f(){;
#74120
Assignees
Labels
A-HIR
Area: The high-level intermediate representation (HIR)
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
P-medium
Medium priority
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
xobs
added
C-bug
jonas-schievink
added
A-HIR
|
Semicolon is not the main problem here. Standalone semicolons are allowed as items inside function body. Second function definition |
spastorino
added
P-medium
|
Prioritized as |
|
@rustbot claim |
|
A possibly clearer repro: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=40cd60c27e0927eba22d2e9667f091e2 extern "C" {
fn f() {
fn g() {}
}
} |
This comment has been minimized.
This comment has been minimized.
|
The previous issue has been fixed, let's try again (sorry for the noise!). |
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this issue
Aug 16, 2020
Don't visit foreign function bodies when lowering ast to hir Previously the existence of bodies inside a foreign function block would cause a panic in the hir `NodeCollector` during its collection of crate bodies to compute a crate hash: https://github.com/rust-lang/rust/blob/e59b08e62ea691916d2f063cac5aab4634128022/src/librustc_middle/hir/map/collector.rs#L154-L158 The collector walks the hir tree and creates a map of hir nodes, then attaching bodies in the crate to their owner in the map. For a code like ```rust extern "C" { fn f() { fn g() {} } } ``` The crate bodies include the body of the function `g`. But foreign functions cannot have bodies, and while the parser AST permits a foreign function to have a body, the hir doesn't. This means that the body of `f` is not present in the hir, and so neither is `g`. So when the `NodeCollector` finishes the walking the hir, it has no record of `g`, cannot find an owner for the body of `g` it sees in the crate bodies, and blows up. Why do the crate bodies include the body of `g`? The AST walker has a need a for walking function bodies, and FFIs share the same AST node as functions in other contexts. There are at least two options to fix this: - Don't unwrap the map entry for an hir node in the `NodeCollector` - Modifier the ast->hir lowering visitor to ignore foreign function blocks I don't think the first is preferrable, since we want to know when we can't find a body for an hir node that we thought had one (dropping this information may lead to an invalid hash). So this commit implements the second option. Closes rust-lang#74120
tmandry
added a commit
to tmandry/rust
that referenced
this issue
Aug 16, 2020
Don't visit foreign function bodies when lowering ast to hir Previously the existence of bodies inside a foreign function block would cause a panic in the hir `NodeCollector` during its collection of crate bodies to compute a crate hash: https://github.com/rust-lang/rust/blob/e59b08e62ea691916d2f063cac5aab4634128022/src/librustc_middle/hir/map/collector.rs#L154-L158 The collector walks the hir tree and creates a map of hir nodes, then attaching bodies in the crate to their owner in the map. For a code like ```rust extern "C" { fn f() { fn g() {} } } ``` The crate bodies include the body of the function `g`. But foreign functions cannot have bodies, and while the parser AST permits a foreign function to have a body, the hir doesn't. This means that the body of `f` is not present in the hir, and so neither is `g`. So when the `NodeCollector` finishes the walking the hir, it has no record of `g`, cannot find an owner for the body of `g` it sees in the crate bodies, and blows up. Why do the crate bodies include the body of `g`? The AST walker has a need a for walking function bodies, and FFIs share the same AST node as functions in other contexts. There are at least two options to fix this: - Don't unwrap the map entry for an hir node in the `NodeCollector` - Modifier the ast->hir lowering visitor to ignore foreign function blocks I don't think the first is preferrable, since we want to know when we can't find a body for an hir node that we thought had one (dropping this information may lead to an invalid hash). So this commit implements the second option. Closes rust-lang#74120
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Code
Meta
rustc --version --verbose:Also occurs on nightly at https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=b87d0d902d835c40f300071f4976ee62
Error output
Backtrace
This issue has been assigned to @ayazhafiz via this comment.
The text was updated successfully, but these errors were encountered: