1

Ensure nested statics have a HIR node to prevent various queries from ICEing by...

 4 weeks ago
source link: https://github.com/rust-lang/rust/pull/122719
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Conversation

Collaborator

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot

added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

labels

Mar 19, 2024

Collaborator

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

Member

Does that test repo the issue? The reporter wrote
…

Contributor

Author

oh fun. I didn't check.

Contributor

Author

I removed the test. The change is useful on its own. We should always have HIR available for all DefIds

Member

Will this also fix the codegen ICEs related to nested statics?

Contributor

Author

no, this PR just makes better ICEs
@@ -3531,7 +3526,8 @@ pub enum Node<'hir> {

WhereBoundPredicate(&'hir WhereBoundPredicate<'hir>),

// FIXME: Merge into `Node::Infer`.

ArrayLenInfer(&'hir InferArg),

AssocOpaqueTy(&'hir AssocOpaqueTy),

// Created by query feeding

Synthetic,

In #120206 and #120943 I specifically wanted to avoid having a non-specific "dummy" node kind.
If we have some HirId or DefId then it's better to know whether it refers to an associated opaque type, or implicit static, or some specific non-synthesized HIR node, at least for debugging.

Contributor

Author

I can give it a field where we can encode the kind of synthetic node that we have here. Then it can be handled the same everywhere and get custom handling where desirable

We usually can get this information by asking for the DefId and then the DefKind, but that's not always immediately there I guess

Member

@fee1-dead fee1-dead

left a comment

LGTM. FWIW, I don't think it is necessary to add any info that distinguishes nested statics from associated types coming from RPITITs, since the def_kind already has it, and we rarely print the HIR after the queries are fed.

Contributor

Author

@bors r=fee1-dead

I'll revisit when we have an actual ICE where it isn't obvious from the query stack already

Contributor

📌 Commit 3a09680 has been approved by fee1-dead

It is now in the queue for this repository.

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

Mar 19, 2024

bors

merged commit 671a2f7 into

rust-lang:master

Mar 19, 2024

11 checks passed

rust-timer

added a commit to rust-lang-ci/rust that referenced this pull request

Mar 19, 2024

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

Reviewers

petrochenkov

petrochenkov left review comments

fee1-dead

fee1-dead approved these changes
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects

None yet

Milestone

1.79.0

Development

Successfully merging this pull request may close these issues.

ICE: hir: index out of bounds

6 participants

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK