Suggest associated type bounds on problematic associated equality bounds#122120
Suggest associated type bounds on problematic associated equality bounds#122120bors merged 4 commits intorust-lang:masterfrom
Conversation
rustbot
added
S-waiting-on-review
fmease
added
S-blocked
| /// | ||
| /// *Bare* trait object types are ones that aren't preceeded by the keyword `dyn`. | ||
| /// In edition 2021 and onward we emit a hard error for them. | ||
| pub(super) fn prohibit_or_lint_bare_trait_object_ty( |
There was a problem hiding this comment.
(esthetics) moves the only non-priv item to the top; all the other items are helpers of this one
There was a problem hiding this comment.
new name is clearer: bare trait? bare trait object (ty); furthermore this isn't “maybe linting” but it's first & foremost prohibiting (if we assume the latest stable edition to be the canonical edition) otherwise linting — in older editions.
| /// $::Debug` that is understood by the astconv code. | ||
| /// ### Examples | ||
| /// | ||
| /// FIXME(alexreg): why have a separate type for the binding case, |
There was a problem hiding this comment.
I never understood this FIXME whenever I came across these docs: The FIXME was created in the same commit as the one that introduced TypeBindingKind in favor of the now gone struct field ty: P<Ty> the FIXME mentions...
|
|
||
| parse_assignment_else_not_allowed = <assignment> ... else {"{"} ... {"}"} is not allowed | ||
|
|
||
| parse_assoc_lifetime = associated lifetimes are not supported |
There was a problem hiding this comment.
This message was confusing imo, it talked about a “fictive” Rust feature, associated lifetimes as if that term was common knowledge. If at all, I would've expected this message to trigger on X<'a = 'static> ('a is the “associated lifetime”, 'static is the “projected lifetime”), not on X<T = 'static> as it currently does on master.
|
:^) thanks |
There was a problem hiding this comment.
We could think about suppressing some of the other trait object type diagnostics.
fmease
added
the
S-waiting-on-author
This comment was marked as resolved.
This comment was marked as resolved.
fmease
force-pushed
the
sugg-assoc-ty-bound-on-eq-bound
branch
from
fd3a91f to
3879acb
Compare
fmease
added
S-waiting-on-review
|
Okay, I've dialed it down. Didn't make anything translatable because if I started doing that I'd find myself in a rabbit hole of updating the neighboring code, too, since it's all interconnected in this case. I also dropped some other changes. I plan on submitting a diagnostic migration PR for r? compiler-errors or compiler, no rush tho |
|
@bors r+ |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#108675 (Document `adt_const_params` feature in Unstable Book) - rust-lang#122120 (Suggest associated type bounds on problematic associated equality bounds) - rust-lang#122589 (Fix diagnostics for async block cloning) - rust-lang#122835 (Require `DerefMut` and `DerefPure` on `deref!()` patterns when appropriate) - rust-lang#123049 (In `ConstructCoroutineInClosureShim`, pass receiver by mut ref, not mut pointer) - rust-lang#123055 (enable cargo miri test doctests) - rust-lang#123057 (unix fs: Make hurd using explicit new rather than From) - rust-lang#123087 (Change `f16` and `f128` clippy stubs to be nonpanicking) - rust-lang#123103 (Rename `Inherited` -> `TypeckRootCtxt`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#122120 - fmease:sugg-assoc-ty-bound-on-eq-bound, r=compiler-errors Suggest associated type bounds on problematic associated equality bounds Fixes rust-lang#105056. TL;DR: Suggest `Trait<Ty: Bound>` on `Trait<Ty = Bound>` in Rust >=2021. ~~Blocked on rust-lang#122055 (stabilization of `associated_type_bounds`), I'd say.~~ (merged)
|
Thanks! |
5 participants
Fixes #105056. TL;DR: Suggest
Trait<Ty: Bound>onTrait<Ty = Bound>in Rust >=2021.Blocked on #122055 (stabilization of(merged)associated_type_bounds), I'd say.