…-bindings, r=compiler-errors

AstConv: Refactor lowering of associated item bindings a bit

Split off from rust-lang#119385 as discussed, namely the first two commits (modulo one `FIXME` getting turned into a `NOTE`).

The second commit removes `astconv::ConvertedBinding{,Kind}` in favor of `hir::TypeBinding{,Kind}`. The former was a — in my opinion — super useless intermediary. As you can tell from the diff, its removal shaves off some code. Furthermore, yeeting it makes it easier to implement the changes in rust-lang#119385.

Nothing in this PR should have any semantic effect.

r? `@compiler-errors`

<sub>**Addendum** as in rust-lang#118668: What I call “associated item bindings” are commonly referred to as “type bindings” for historical reasons. Nowadays, “type bindings” include assoc type bindings, assoc const bindings and RTN (return type notation) which is why I prefer not to use this outdated term.</sub>

…-bindings, r=compiler-errors

AstConv: Refactor lowering of associated item bindings a bit

Split off from rust-lang#119385 as discussed, namely the first two commits (modulo one `FIXME` getting turned into a `NOTE`).

The second commit removes `astconv::ConvertedBinding{,Kind}` in favor of `hir::TypeBinding{,Kind}`. The former was a — in my opinion — super useless intermediary. As you can tell from the diff, its removal shaves off some code. Furthermore, yeeting it will make it easier to implement the type resolution fixes in rust-lang#119385.

Nothing in this PR should have any semantic effect.

r? `@compiler-errors`

<sub>**Addendum** as in rust-lang#118668: What I call “associated item bindings” are commonly referred to as “type bindings” for historical reasons. Nowadays, “type bindings” include assoc type bindings, assoc const bindings and RTN (return type notation) which is why I prefer not to use this outdated term.</sub>

Rollup merge of rust-lang#121221 - fmease:refactor-astconv-assoc-item-bindings, r=compiler-errors

AstConv: Refactor lowering of associated item bindings a bit

Split off from rust-lang#119385 as discussed, namely the first two commits (modulo one `FIXME` getting turned into a `NOTE`).

The second commit removes `astconv::ConvertedBinding{,Kind}` in favor of `hir::TypeBinding{,Kind}`. The former was a — in my opinion — super useless intermediary. As you can tell from the diff, its removal shaves off some code. Furthermore, yeeting it will make it easier to implement the type resolution fixes in rust-lang#119385.

Nothing in this PR should have any semantic effect.

r? `@compiler-errors`

<sub>**Addendum** as in rust-lang#118668: What I call “associated item bindings” are commonly referred to as “type bindings” for historical reasons. Nowadays, “type bindings” include assoc type bindings, assoc const bindings and RTN (return type notation) which is why I prefer not to use this outdated term.</sub>

…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`

…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``

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``

…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.

…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.

…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.

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.

…r=compiler-errors

HIR ty lowering: Clean up & refactor the lowering of type-relative paths

While rebasing rust-lang#126651 I realized that HIR ty lowering could benefit from some *spring cleaning* now that it's been extended to handle RTN and mGCA paths.

More seriously, similar to my merged PR rust-lang#118668 which unified the handling of all *associated item constraints* (assoc ty, const (ACE) & fn (RTN)), this PR (commit rust-lang@695fcf5) partially[^1] deduplicates the resolution code for all *type-relative paths* (assoc ty, const (mGCA) & fn (RTN)).

**Why**? DRY'ing that part of the code means PR rust-lang#126651 will automatically support RTN paths like `Ty::AssocTy::assoc_fn(..)` and it also implies shared diagnostic code and thus better diagnostics for RTN.

---

The other commits represent cleanups, renamings, moves. More notably, I've renamed path lowering methods to be a lot more descriptive, so ones lowering `QPath(Resolved)` paths now have `_resolved_` in their name and ones lowering `QPath(TypeRelative)` paths now have `_type_relative_` in their name. This should make it stupidly obvious what their purpose is.

---

Best reviewed commit by commit. The changes are close to trivial but the diff might make it look hairier.
r? compiler-errors

[^1]: Sadly, I couldn't unify as much compared to the other PR without introducing unnecessary `unreachable!()`s or rendering the code otherwise illegible with flags and micro helper traits.

Rollup merge of rust-lang#140218 - fmease:hirtylo-clean-up-path-low, r=compiler-errors

HIR ty lowering: Clean up & refactor the lowering of type-relative paths

While rebasing rust-lang#126651 I realized that HIR ty lowering could benefit from some *spring cleaning* now that it's been extended to handle RTN and mGCA paths.

More seriously, similar to my merged PR rust-lang#118668 which unified the handling of all *associated item constraints* (assoc ty, const (ACE) & fn (RTN)), this PR (commit rust-lang@695fcf5) partially[^1] deduplicates the resolution code for all *type-relative paths* (assoc ty, const (mGCA) & fn (RTN)).

**Why**? DRY'ing that part of the code means PR rust-lang#126651 will automatically support RTN paths like `Ty::AssocTy::assoc_fn(..)` and it also implies shared diagnostic code and thus better diagnostics for RTN.

---

The other commits represent cleanups, renamings, moves. More notably, I've renamed path lowering methods to be a lot more descriptive, so ones lowering `QPath(Resolved)` paths now have `_resolved_` in their name and ones lowering `QPath(TypeRelative)` paths now have `_type_relative_` in their name. This should make it stupidly obvious what their purpose is.

---

Best reviewed commit by commit. The changes are close to trivial but the diff might make it look hairier.
r? compiler-errors

[^1]: Sadly, I couldn't unify as much compared to the other PR without introducing unnecessary `unreachable!()`s or rendering the code otherwise illegible with flags and micro helper traits.