Remove support for `associated_type_bound` nested in `dyn` types by compiler-errors · Pull Request #120719 · rust-lang/rust

compiler-errors · 2024-02-06T19:50:24Z

These necessarily desugar to impl Trait, which is inconsistent with the associated_type_bound feature after #120584.

This PR keeps the is_in_dyn_type hack, which kind of makes me sad. Ideally, we'd be validating that no object types have associated type bounds somewhere else. Unfortunately, we can't do this later during astconv (i think?), nor can we do it earlier during ast validation (i think?) because of the feature gating of ATB being a warning rather than an error. Let me know if you have thoughts about this.

r? lcnr

bors · 2024-02-07T06:30:40Z

☔ The latest upstream changes (presumably #118257) made this pull request unmergeable. Please resolve the merge conflicts.

lcnr

I think is_in_dyn_type is just a more specific version of "in type". So maybe just changing this to "in_type" seems a bit nicer as it's more general, but really 🤷

compiler/rustc_ast_lowering/messages.ftl

compiler/rustc_ast_lowering/src/lib.rs

lcnr · 2024-02-08T08:35:14Z

r=me after nits

compiler-errors · 2024-02-08T15:28:56Z

I'm gonna land this after #120584, since it conflicts.

bors · 2024-02-09T00:01:30Z

☔ The latest upstream changes (presumably #120807) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2024-02-10T03:08:40Z

☔ The latest upstream changes (presumably #120862) made this pull request unmergeable. Please resolve the merge conflicts.

compiler-errors · 2024-02-10T03:32:49Z

@bors r=lcnr

bors · 2024-02-10T03:32:51Z

📌 Commit fde695a has been approved by lcnr

It is now in the queue for this repository.

compiler-errors · 2024-02-10T03:53:22Z

Removing DesugarKind::ImplTrait caused us to have an unused fn, removed that.

@bors r=lcnr

bors · 2024-02-10T03:53:25Z

📌 Commit e6f5af9 has been approved by lcnr

It is now in the queue for this repository.

Remove support for `associated_type_bound` nested in `dyn` types These necessarily desugar to `impl Trait`, which is inconsistent with the `associated_type_bound` feature after rust-lang#120584. This PR keeps the `is_in_dyn_type` hack, which kind of makes me sad. Ideally, we'd be validating that no object types have associated type bounds somewhere else. Unfortunately, we can't do this later during astconv (i think?), nor can we do it earlier during ast validation (i think?) because of the feature gating of ATB being a *warning* rather than an *error*. Let me know if you have thoughts about this. r? lcnr

…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#117614 (static mut: allow mutable reference to arbitrary types, not just slices and arrays) - rust-lang#120588 (wasm: Store rlib metadata in wasm object files) - rust-lang#120719 (Remove support for `associated_type_bound` nested in `dyn` types) - rust-lang#120823 (Clarify that atomic and regular integers can differ in alignment) - rust-lang#120859 (Loosen an assertion to account for stashed errors.) - rust-lang#120865 (Turn the "no saved object file in work product" ICE into a translatable fatal error) - rust-lang#120866 (Remove unnecessary `#![feature(min_specialization)]`) - rust-lang#120870 (Allow restricted trait impls under `#[allow_internal_unstable(min_specialization)]`) r? `@ghost` `@rustbot` modify labels: rollup

…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#117614 (static mut: allow mutable reference to arbitrary types, not just slices and arrays) - rust-lang#120719 (Remove support for `associated_type_bound` nested in `dyn` types) - rust-lang#120764 (Add documentation on `str::starts_with`) - rust-lang#120823 (Clarify that atomic and regular integers can differ in alignment) - rust-lang#120859 (Loosen an assertion to account for stashed errors.) - rust-lang#120865 (Turn the "no saved object file in work product" ICE into a translatable fatal error) - rust-lang#120866 (Remove unnecessary `#![feature(min_specialization)]`) - rust-lang#120870 (Allow restricted trait impls under `#[allow_internal_unstable(min_specialization)]`) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#120719 - compiler-errors:no-dyn-atb, r=lcnr Remove support for `associated_type_bound` nested in `dyn` types These necessarily desugar to `impl Trait`, which is inconsistent with the `associated_type_bound` feature after rust-lang#120584. This PR keeps the `is_in_dyn_type` hack, which kind of makes me sad. Ideally, we'd be validating that no object types have associated type bounds somewhere else. Unfortunately, we can't do this later during astconv (i think?), nor can we do it earlier during ast validation (i think?) because of the feature gating of ATB being a *warning* rather than an *error*. Let me know if you have thoughts about this. r? lcnr

…li-obk Stabilize associated type bounds (RFC 2289) This PR stabilizes associated type bounds, which were laid out in [RFC 2289]. This gives us a shorthand to express nested type bounds that would otherwise need to be expressed with nested `impl Trait` or broken into several `where` clauses. ### What are we stabilizing? We're stabilizing the associated item bounds syntax, which allows us to put bounds in associated type position within other bounds, i.e. `T: Trait<Assoc: Bounds...>`. See [RFC 2289] for motivation. In all position, the associated type bound syntax expands into a set of two (or more) bounds, and never anything else (see "How does this differ[...]" section for more info). Associated type bounds are stabilized in four positions: * **`where` clauses (and APIT)** - This is equivalent to breaking up the bound into two (or more) `where` clauses. For example, `where T: Trait<Assoc: Bound>` is equivalent to `where T: Trait, <T as Trait>::Assoc: Bound`. * **Supertraits** - Similar to above, `trait CopyIterator: Iterator<Item: Copy> {}`. This is almost equivalent to breaking up the bound into two (or more) `where` clauses; however, the bound on the associated item is implied whenever the trait is used. See rust-lang#112573/rust-lang#112629. * **Associated type item bounds** - This allows constraining the *nested* rigid projections that are associated with a trait's associated types. e.g. `trait Trait { type Assoc: Trait2<Assoc2: Copy>; }`. * **opaque item bounds (RPIT, TAIT)** - This allows constraining associated types that are associated with the opaque without having to *name* the opaque. For example, `impl Iterator<Item: Copy>` defines an iterator whose item is `Copy` without having to actually name that item bound. The latter three are not expressible in surface Rust (though for associated type item bounds, this will change in rust-lang#120752, which I don't believe should block this PR), so this does represent a slight expansion of what can be expressed in trait bounds. ### How does this differ from the RFC? Compared to the RFC, the current implementation *always* desugars associated type bounds to sets of `ty::Clause`s internally. Specifically, it does *not* introduce a position-dependent desugaring as laid out in [RFC 2289], and in particular: * It does *not* desugar to anonymous associated items in associated type item bounds. * It does *not* desugar to nested RPITs in RPIT bounds, nor nested TAITs in TAIT bounds. This position-dependent desugaring laid out in the RFC existed simply to side-step limitations of the trait solver, which have mostly been fixed in rust-lang#120584. The desugaring laid out in the RFC also added unnecessary complication to the design of the feature, and introduces its own limitations to, for example: * Conditionally lowering to nested `impl Trait` in certain positions such as RPIT and TAIT means that we inherit the limitations of RPIT/TAIT, namely lack of support for higher-ranked opaque inference. See this code example: rust-lang#120752 (comment). * Introducing anonymous associated types makes traits no longer object safe, since anonymous associated types are not nameable, and all associated types must be named in `dyn` types. This last point motivates why this PR is *not* stabilizing support for associated type bounds in `dyn` types, e.g, `dyn Assoc<Item: Bound>`. Why? Because `dyn` types need to have *concrete* types for all associated items, this would necessitate a distinct lowering for associated type bounds, which seems both complicated and unnecessary compared to just requiring the user to write `impl Trait` themselves. See rust-lang#120719. ### Implementation history: Limited to the significant behavioral changes and fixes and relevant PRs, ping me if I left something out-- * rust-lang#57428 * rust-lang#108063 * rust-lang#110512 * rust-lang#112629 * rust-lang#120719 * rust-lang#120584 Closes rust-lang#52662 [RFC 2289]: https://rust-lang.github.io/rfcs/2289-associated-type-bounds.html

…-obk Stabilize associated type bounds (RFC 2289) This PR stabilizes associated type bounds, which were laid out in [RFC 2289]. This gives us a shorthand to express nested type bounds that would otherwise need to be expressed with nested `impl Trait` or broken into several `where` clauses. ### What are we stabilizing? We're stabilizing the associated item bounds syntax, which allows us to put bounds in associated type position within other bounds, i.e. `T: Trait<Assoc: Bounds...>`. See [RFC 2289] for motivation. In all position, the associated type bound syntax expands into a set of two (or more) bounds, and never anything else (see "How does this differ[...]" section for more info). Associated type bounds are stabilized in four positions: * **`where` clauses (and APIT)** - This is equivalent to breaking up the bound into two (or more) `where` clauses. For example, `where T: Trait<Assoc: Bound>` is equivalent to `where T: Trait, <T as Trait>::Assoc: Bound`. * **Supertraits** - Similar to above, `trait CopyIterator: Iterator<Item: Copy> {}`. This is almost equivalent to breaking up the bound into two (or more) `where` clauses; however, the bound on the associated item is implied whenever the trait is used. See rust-lang#112573/rust-lang#112629. * **Associated type item bounds** - This allows constraining the *nested* rigid projections that are associated with a trait's associated types. e.g. `trait Trait { type Assoc: Trait2<Assoc2: Copy>; }`. * **opaque item bounds (RPIT, TAIT)** - This allows constraining associated types that are associated with the opaque without having to *name* the opaque. For example, `impl Iterator<Item: Copy>` defines an iterator whose item is `Copy` without having to actually name that item bound. The latter three are not expressible in surface Rust (though for associated type item bounds, this will change in rust-lang#120752, which I don't believe should block this PR), so this does represent a slight expansion of what can be expressed in trait bounds. ### How does this differ from the RFC? Compared to the RFC, the current implementation *always* desugars associated type bounds to sets of `ty::Clause`s internally. Specifically, it does *not* introduce a position-dependent desugaring as laid out in [RFC 2289], and in particular: * It does *not* desugar to anonymous associated items in associated type item bounds. * It does *not* desugar to nested RPITs in RPIT bounds, nor nested TAITs in TAIT bounds. This position-dependent desugaring laid out in the RFC existed simply to side-step limitations of the trait solver, which have mostly been fixed in rust-lang#120584. The desugaring laid out in the RFC also added unnecessary complication to the design of the feature, and introduces its own limitations to, for example: * Conditionally lowering to nested `impl Trait` in certain positions such as RPIT and TAIT means that we inherit the limitations of RPIT/TAIT, namely lack of support for higher-ranked opaque inference. See this code example: rust-lang#120752 (comment). * Introducing anonymous associated types makes traits no longer object safe, since anonymous associated types are not nameable, and all associated types must be named in `dyn` types. This last point motivates why this PR is *not* stabilizing support for associated type bounds in `dyn` types, e.g, `dyn Assoc<Item: Bound>`. Why? Because `dyn` types need to have *concrete* types for all associated items, this would necessitate a distinct lowering for associated type bounds, which seems both complicated and unnecessary compared to just requiring the user to write `impl Trait` themselves. See rust-lang#120719. ### Implementation history: Limited to the significant behavioral changes and fixes and relevant PRs, ping me if I left something out-- * rust-lang#57428 * rust-lang#108063 * rust-lang#110512 * rust-lang#112629 * rust-lang#120719 * rust-lang#120584 Closes rust-lang#52662 [RFC 2289]: https://rust-lang.github.io/rfcs/2289-associated-type-bounds.html

rustbot assigned lcnr Feb 6, 2024

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 Feb 6, 2024

rust-cloud-vms bot force-pushed the no-dyn-atb branch from aacbd8e to 661ceaf Compare February 7, 2024 15:13

lcnr reviewed Feb 8, 2024

View reviewed changes

compiler/rustc_ast_lowering/messages.ftl Outdated Show resolved Hide resolved

compiler/rustc_ast_lowering/src/lib.rs Outdated Show resolved Hide resolved

lcnr mentioned this pull request Feb 8, 2024

Tracking issue for RFC 2289, "Associated type bounds" #52662

Closed

9 tasks

rust-cloud-vms bot force-pushed the no-dyn-atb branch from 661ceaf to fa92bf8 Compare February 8, 2024 15:01

rust-cloud-vms bot force-pushed the no-dyn-atb branch from fa92bf8 to 6e6d8a1 Compare February 9, 2024 00:11

compiler-errors added 2 commits February 10, 2024 03:23

No more associated type bounds in dyn trait

973bbfb

Add a helpful suggestion

fde695a

rust-cloud-vms bot force-pushed the no-dyn-atb branch from 6e6d8a1 to fde695a Compare February 10, 2024 03:31

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 Feb 10, 2024

This comment has been minimized.

Sign in to view

Remove unused fn

e6f5af9

matthiaskrgr mentioned this pull request Feb 10, 2024

Rollup of 9 pull requests #120875

Closed

matthiaskrgr mentioned this pull request Feb 10, 2024

Rollup of 8 pull requests #120876

Closed

matthiaskrgr mentioned this pull request Feb 10, 2024

Rollup of 8 pull requests #120877

Merged

bors merged commit e11e444 into rust-lang:master Feb 10, 2024

rustbot added this to the 1.78.0 milestone Feb 10, 2024

compiler-errors mentioned this pull request Mar 6, 2024

Stabilize associated type bounds (RFC 2289) #122055

Merged

moxian mentioned this pull request May 26, 2025

ICE: unexpected ambiguity: CanonicalQueryInput - broken MIR #141478

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Remove support for `associated_type_bound` nested in `dyn` types#120719

Remove support for `associated_type_bound` nested in `dyn` types#120719
bors merged 3 commits intorust-lang:masterfrom
compiler-errors:no-dyn-atb

compiler-errors commented Feb 6, 2024

Uh oh!

bors commented Feb 7, 2024

Uh oh!

lcnr left a comment

Uh oh!

Uh oh!

Uh oh!

lcnr commented Feb 8, 2024

Uh oh!

compiler-errors commented Feb 8, 2024

Uh oh!

bors commented Feb 9, 2024

Uh oh!

bors commented Feb 10, 2024

Uh oh!

compiler-errors commented Feb 10, 2024

Uh oh!

bors commented Feb 10, 2024

Uh oh!

This comment has been minimized.

compiler-errors commented Feb 10, 2024

Uh oh!

bors commented Feb 10, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

compiler-errors commented Feb 6, 2024

Uh oh!

bors commented Feb 7, 2024

Uh oh!

lcnr left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

lcnr commented Feb 8, 2024

Uh oh!

compiler-errors commented Feb 8, 2024

Uh oh!

bors commented Feb 9, 2024

Uh oh!

bors commented Feb 10, 2024

Uh oh!

compiler-errors commented Feb 10, 2024

Uh oh!

bors commented Feb 10, 2024

Uh oh!

This comment has been minimized.

compiler-errors commented Feb 10, 2024

Uh oh!

bors commented Feb 10, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants