Skip to content

Conversation

mu001999
Copy link
Contributor

Fixes #125757

@rustbot
Copy link
Collaborator

rustbot commented May 30, 2024

r? @petrochenkov

rustbot has assigned @petrochenkov.
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 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 May 30, 2024
@petrochenkov
Copy link
Contributor

r? types

@rustbot rustbot added the T-types Relevant to the types team, which will review and decide on the PR/issue. label May 30, 2024
@rustbot rustbot assigned jackh726 and unassigned petrochenkov May 30, 2024
Copy link
Member

@compiler-errors compiler-errors left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe this is the correct fix for the issue.

@compiler-errors
Copy link
Member

I think the correct fix here would be to just stop unwrapping here and more gracefully handle the case where the diagnostic has no error code:

if tcx.sess.teach(diag.code.unwrap()) {

Though it would be most thorough to first explain why we're calling the expected_projection method here at all.

@mu001999
Copy link
Contributor Author

@compiler-errors how about the new change? I added a boolean to check the type is used as the type of a constant, which is forbidden.

@compiler-errors
Copy link
Member

This still seems like not the correct approach. What is wrong with the approach that I suggested in #125774 (comment)?

@mu001999 mu001999 changed the title Skip expected_projection if proj_ty is forbidden Avoid unwrap diag.code directly in note_and_explain_type_err May 30, 2024
@mu001999
Copy link
Contributor Author

@compiler-errors I tried this when I first touched this issue, it works indeed. But after skimming through the call logic, I just think we shouldn't call expected_projection if the projection appeared in a forbidden context, then we also don't want the new helps like:

   = help: consider constraining the associated type `<i32 as Trait>::Type` to `usize`

But I agree that current approach is enough.

@rust-log-analyzer

This comment has been minimized.

@compiler-errors
Copy link
Member

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented May 31, 2024

📌 Commit ed5205f has been approved by compiler-errors

It is now in the queue for this repository.

@bors 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 May 31, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request May 31, 2024
…iaskrgr

Rollup of 4 pull requests

Successful merges:

 - rust-lang#125635 (Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanup)
 - rust-lang#125774 (Avoid unwrap diag.code directly in note_and_explain_type_err)
 - rust-lang#125786 (Fold item bounds before proving them in `check_type_bounds` in new solver)
 - rust-lang#125790 (Don't recompute `tail` in `lower_stmts`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 4aafc11 into rust-lang:master May 31, 2024
@rustbot rustbot added this to the 1.80.0 milestone May 31, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request May 31, 2024
Rollup merge of rust-lang#125774 - mu001999-contrib:fix/125757, r=compiler-errors

Avoid unwrap diag.code directly in note_and_explain_type_err

<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.

This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using

    r​? <reviewer name>
-->

Fixes rust-lang#125757
@mu001999 mu001999 deleted the fix/125757 branch June 26, 2024 14:10
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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ICE: called Option::unwrap() on a None value in compiler/rustc_infer/src/infer/error_reporting/note_and_explain.rs
7 participants