-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Don't visit foreign function bodies when lowering ast to hir #74204
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
label
Jul 10, 2020
eddyb
reviewed
Jul 15, 2020
eddyb
added
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Jul 15, 2020
eddyb
reviewed
Jul 15, 2020
JohnTitor
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Jul 26, 2020
@eddyb friendly ping for this :) |
Ugh I should've mentioned that you should PM me on Zulip once you've addressed the comments. |
eddyb
approved these changes
Aug 16, 2020
@bors r+ |
📌 Commit d442bf7 has been approved by |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Aug 16, 2020
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
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
⌛ Testing commit d442bf7 with merge 57c460f246822f269a5c8c3df7f9787c37e3dd13... |
Rolled up, |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 16, 2020
Rollup of 10 pull requests Successful merges: - rust-lang#74204 (Don't visit foreign function bodies when lowering ast to hir) - rust-lang#74314 (rustc_typeck: construct {Closure,Generator}Substs more directly.) - rust-lang#74346 (Use LocalDefId instead of HirId for reachable_set elements.) - rust-lang#74399 (Move DelaySpanBugEmitted to ty::context) - rust-lang#75177 (Add regression test for issue-66768) - rust-lang#75223 (Add #[track_caller] to `Session::delay_span_bug`) - rust-lang#75423 (Move to intra-doc links for /library/core/src/hint.rs) - rust-lang#75485 (pin docs: add some forward references) - rust-lang#75569 (Bump minor version of emsdk to 1.38.47) - rust-lang#75596 (Switch to intra-doc links in /sys/windows/ext/{ffi,fs,process}.rs) Failed merges: r? @ghost
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jan 6, 2022
…=cjgillot Don't resolve blocks in foreign functions Although it is an error for a foreign function to have a block, it is still possible at the level of the AST. rust-lang#74204 made AST lowering skip over blocks belonging to foreign functions, since they're invalid. However, resolve still treated these blocks normally, resulting in a mismatch between the HIR and resolve, which could cause an ICE under certain circumstances. This PR changes resolve to skip over blocks belonging to foreign functions, as AST lowering does. Fixes rust-lang#91370. r? `@cjgillot`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jan 9, 2022
…=cjgillot Don't resolve blocks in foreign functions Although it is an error for a foreign function to have a block, it is still possible at the level of the AST. rust-lang#74204 made AST lowering skip over blocks belonging to foreign functions, since they're invalid. However, resolve still treated these blocks normally, resulting in a mismatch between the HIR and resolve, which could cause an ICE under certain circumstances. This PR changes resolve to skip over blocks belonging to foreign functions, as AST lowering does. Fixes rust-lang#91370. r? ``@cjgillot``
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously the existence of bodies inside a foreign function block would
cause a panic in the hir
NodeCollector
during its collection of cratebodies to compute a crate hash:
rust/src/librustc_middle/hir/map/collector.rs
Lines 154 to 158 in e59b08e
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
The crate bodies include the body of the function
g
. But foreignfunctions 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 isg
. So when theNodeCollector
finishes the walking the hir, it has no record ofg
,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 aneed 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:
NodeCollector
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 #74120