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

Fix type resolution of associated const equality bounds (take 2) #119385

Merged
merged 3 commits into from
Mar 11, 2024

Conversation

fmease
Copy link
Member

@fmease fmease commented Dec 28, 2023

Instead of trying to re-resolve the type of assoc const bindings inside the type_of query impl in an incomplete manner, transfer the already (correctly) resolved type from add_predicates_for_ast_type_binding to type_of/anon_type_of through query feeding.


Together with #118668 (merged) and #121258, this supersedes #118360.
Fixes #118040.

r? @ghost

@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 Dec 28, 2023
@fmease fmease added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-types Relevant to the types team, which will review and decide on the PR/issue. F-associated_const_equality `#![feature(associated_const_equality)]` and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 28, 2023
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

let term: ty::Term<'_> = match term {
hir::Term::Ty(ty) => self.ast_ty_to_ty(ty).into(),
hir::Term::Const(ct) => {
ty::Const::from_anon_const(tcx, ct.def_id).into()
Copy link
Member Author

@fmease fmease Jan 10, 2024

Choose a reason for hiding this comment

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

This might leak {type error} since we haven't actually resolved & feed the type to type_of(AnonConst) if we reach this case. The pretty-printer doesn't seem to care though (not sure if it can actually crash on certain inputs involving ty::TyKind::Error though).

Alternatively, I could pretty-print the HIR of the const but I'd need to create a public helper, const_to_string, since rustc_hir_pretty doesn't seem to expose anything like that yet?

@fmease fmease force-pushed the assoc-const-eq-fixes-2 branch 3 times, most recently from 7938112 to ecf2aba Compare January 10, 2024 15:35
@fmease fmease changed the title [WIP] Fix type resolution of associated const equality bounds (take 2) Fix type resolution of associated const equality bounds (take 2) Jan 10, 2024
@fmease fmease marked this pull request as ready for review January 10, 2024 15:58
@rust-lang rust-lang deleted a comment from rustbot Jan 10, 2024
@fmease
Copy link
Member Author

fmease commented Jan 10, 2024

Best reviewed commit by commit.
r? compiler-errors (no rush though)

@fmease fmease 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 Jan 10, 2024
@bors

This comment was marked as outdated.

@fmease fmease force-pushed the assoc-const-eq-fixes-2 branch 3 times, most recently from cfc3f0f to ca6ac84 Compare January 14, 2024 11:33
@oli-obk
Copy link
Contributor

oli-obk commented Feb 21, 2024

We can directly feed the AnonConst's type instead of adding another indirection.

Ideally we'd only create the AnonConst's DefId right here, but since that can't be done for the other uses of AnonConsts yet, we still have to wait a bit before cleaning this up.

@fmease
Copy link
Member Author

fmease commented Feb 23, 2024

We can directly feed the AnonConst's type instead of adding another indirection.

Oh, that makes perfect sense, thanks! Apart from eliminating indirection, does your change affect incremental query evaluation? Just out of curiosity I'd like to ask if the previous approach was unsound?

As for next steps, is this change ready to be merged? Who should review it lol?

@rust-log-analyzer

This comment has been minimized.

@fmease

This comment was marked as resolved.

@oli-obk
Copy link
Contributor

oli-obk commented Feb 23, 2024

Just out of curiosity I'd to ask if the previous approach was unsound?

It fed a hir id query, which we haven't considered yet at all. We could have marked whichever query did that as depending on the forever red node, meaning it would get rerun always. That would have been sound, but horrible for perf.

Then again, it's not really worse than what I did with the other query, just fewer moving parts. Also DefIds are a bit more stable than hir ids, due to their tree style relative nature.

I did not think about hir id query feeding soundness too much, so it may have been fine

@oli-obk
Copy link
Contributor

oli-obk commented Feb 23, 2024

Just out of curiosity I'd to ask if the previous approach was unsound?

It fed a hir id query, which we haven't considered yet at all. We could have marked whichever query did that as depending on the forever red node, meaning it would get rerun always. That would have been sound, but horrible for perf.

Then again, it's not really worse than what I did with the other query, just fewer moving parts. Also DefIds are a bit more stable than hir ids, due to their tree style relative nature.

I did not think about hir id query feeding soundness too much, so it may have been fine

As for next steps, is this change ready to be merged? Who should review it lol?

We can cross review each other's changes 😅 or get cjgillot to chime in

@fmease
Copy link
Member Author

fmease commented Feb 27, 2024

Hey, @cjgillot. If you have time and energy, could you skim this PR and double-check if the query feeding performed here roughly makes sense from a soundness perspective wrt. incr comp? Thanks a lot in advance!

We can cross review each other's changes

Otherwise the changes look good to me!

@compiler-errors compiler-errors removed their assignment Mar 4, 2024
@cjgillot
Copy link
Contributor

LGTM. Sorry for the delay.
@bors r=oli-obk,cjgillot

@bors
Copy link
Contributor

bors commented Mar 10, 2024

📌 Commit 858d336 has been approved by oli-obk,cjgillot

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 Mar 10, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 11, 2024
…li-obk,cjgillot

Fix type resolution of associated const equality bounds (take 2)

Instead of trying to re-resolve the type of assoc const bindings inside the `type_of` query impl in an incomplete manner, transfer the already (correctly) resolved type from `add_predicates_for_ast_type_binding` to `type_of`/`anon_type_of` through query feeding.

---

Together with rust-lang#118668 (merged) and rust-lang#121258, this supersedes rust-lang#118360.
Fixes rust-lang#118040.

r? `@ghost`
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 11, 2024
…kingjubilee

Rollup of 15 pull requests

Successful merges:

 - rust-lang#116791 (Allow codegen backends to opt-out of parallel codegen)
 - rust-lang#116793 (Allow targets to override default codegen backend)
 - rust-lang#117458 (LLVM Bitcode Linker: A self contained linker for nvptx and other targets)
 - rust-lang#119385 (Fix type resolution of associated const equality bounds (take 2))
 - rust-lang#121438 (std support for wasm32 panic=unwind)
 - rust-lang#121893 (Add tests (and a bit of cleanup) for interior mut handling in promotion and const-checking)
 - rust-lang#122080 (Clarity improvements to `DropTree`)
 - rust-lang#122152 (Improve diagnostics for parenthesized type arguments)
 - rust-lang#122166 (Remove the unused `field_remapping` field from `TypeLowering`)
 - rust-lang#122249 (interpret: do not call machine read hooks during validation)
 - rust-lang#122299 (Store backtrace for `must_produce_diag`)
 - rust-lang#122318 (Revision-related tweaks for next-solver tests)
 - rust-lang#122320 (Use ptradd for vtable indexing)
 - rust-lang#122328 (unix_sigpipe: Replace `inherit` with `sig_dfl` in syntax tests)
 - rust-lang#122330 (bootstrap readme: fix, improve, update)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit a450339 into rust-lang:master Mar 11, 2024
11 checks passed
@rustbot rustbot added this to the 1.78.0 milestone Mar 11, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 11, 2024
Rollup merge of rust-lang#119385 - fmease:assoc-const-eq-fixes-2, r=oli-obk,cjgillot

Fix type resolution of associated const equality bounds (take 2)

Instead of trying to re-resolve the type of assoc const bindings inside the `type_of` query impl in an incomplete manner, transfer the already (correctly) resolved type from `add_predicates_for_ast_type_binding` to `type_of`/`anon_type_of` through query feeding.

---

Together with rust-lang#118668 (merged) and rust-lang#121258, this supersedes rust-lang#118360.
Fixes rust-lang#118040.

r? ``@ghost``
@fmease fmease deleted the assoc-const-eq-fixes-2 branch March 11, 2024 19:41
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Mar 18, 2024
…y-generic-tys, r=compiler-errors

Reject overly generic assoc const binding types

Split off from rust-lang#119385 to make rust-lang#119385 easier to review.

---

In the *instantiated* type of assoc const bindings

1. reject **early-bound generic params**
   * Provide a rich error message instead of ICE'ing ([rust-lang#108271](rust-lang#108271)).
   * This is a temporary and semi-artificial restriction until the arrival of *generic const generics*.
   * It's quite possible that rustc could already perfectly support this subset of generic const generics if we just removed some checks (some `.no_bound_vars().expect(…)`) but even if that was the case, I'd rather gate it behind a new feature flag. Reporting an error instead of ICE'ing is a good first step towards an eventual feature gate error.
2. reject **escaping late-bound generic params**
   * They lead to ICEs before & I'm pretty sure that they remain incorrect even in a world with *generic const generics*

---

Together with rust-lang#118668 & rust-lang#119385, this supersedes rust-lang#118360.
Fixes rust-lang#108271.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 18, 2024
…y-generic-tys, r=compiler-errors

Reject overly generic assoc const binding types

Split off from rust-lang#119385 to make rust-lang#119385 easier to review.

---

In the *instantiated* type of assoc const bindings

1. reject **early-bound generic params**
   * Provide a rich error message instead of ICE'ing ([rust-lang#108271](rust-lang#108271)).
   * This is a temporary and semi-artificial restriction until the arrival of *generic const generics*.
   * It's quite possible that rustc could already perfectly support this subset of generic const generics if we just removed some checks (some `.no_bound_vars().expect(…)`) but even if that was the case, I'd rather gate it behind a new feature flag. Reporting an error instead of ICE'ing is a good first step towards an eventual feature gate error.
2. reject **escaping late-bound generic params**
   * They lead to ICEs before & I'm pretty sure that they remain incorrect even in a world with *generic const generics*

---

Together with rust-lang#118668 & rust-lang#119385, this supersedes rust-lang#118360.
Fixes rust-lang#108271.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 18, 2024
…y-generic-tys, r=compiler-errors

Reject overly generic assoc const binding types

Split off from rust-lang#119385 to make rust-lang#119385 easier to review.

---

In the *instantiated* type of assoc const bindings

1. reject **early-bound generic params**
   * Provide a rich error message instead of ICE'ing ([rust-lang#108271](rust-lang#108271)).
   * This is a temporary and semi-artificial restriction until the arrival of *generic const generics*.
   * It's quite possible that rustc could already perfectly support this subset of generic const generics if we just removed some checks (some `.no_bound_vars().expect(…)`) but even if that was the case, I'd rather gate it behind a new feature flag. Reporting an error instead of ICE'ing is a good first step towards an eventual feature gate error.
2. reject **escaping late-bound generic params**
   * They lead to ICEs before & I'm pretty sure that they remain incorrect even in a world with *generic const generics*

---

Together with rust-lang#118668 & rust-lang#119385, this supersedes rust-lang#118360.
Fixes rust-lang#108271.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 18, 2024
Rollup merge of rust-lang#121258 - fmease:assoc-const-eq-reject-overly-generic-tys, r=compiler-errors

Reject overly generic assoc const binding types

Split off from rust-lang#119385 to make rust-lang#119385 easier to review.

---

In the *instantiated* type of assoc const bindings

1. reject **early-bound generic params**
   * Provide a rich error message instead of ICE'ing ([rust-lang#108271](rust-lang#108271)).
   * This is a temporary and semi-artificial restriction until the arrival of *generic const generics*.
   * It's quite possible that rustc could already perfectly support this subset of generic const generics if we just removed some checks (some `.no_bound_vars().expect(…)`) but even if that was the case, I'd rather gate it behind a new feature flag. Reporting an error instead of ICE'ing is a good first step towards an eventual feature gate error.
2. reject **escaping late-bound generic params**
   * They lead to ICEs before & I'm pretty sure that they remain incorrect even in a world with *generic const generics*

---

Together with rust-lang#118668 & rust-lang#119385, this supersedes rust-lang#118360.
Fixes rust-lang#108271.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-associated_const_equality `#![feature(associated_const_equality)]` 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.

ICEs with assoc const equality where assoc const comes from supertrait
7 participants