Don't ICE on return-type notation when promoting trait preds to associated type bounds #111861
Conversation
|
r? @jackh726 (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
rust-cloud-vms
bot
force-pushed
the
rtn-in-super
branch
from
5c9104b
to
e54bc1c
Compare
| // FIXME(return_type_notation): This check should be more robust | ||
| && !tcx.is_impl_trait_in_trait(projection.def_id) |
There was a problem hiding this comment.
This seems just incomplete and a not so great hack.
If the return type is not an impl Trait, doesn't it work fine? If so, why?
If everything works as expected, this at least needs a bit more documentation on why this hack exists.
There was a problem hiding this comment.
We can encounter precisely two types of items for the projection.def_id here:
- Associated types/consts
- return-position impl trait in trait, when using RTN
If the return type is not an RPITIT, then it's always going to be an associated type or const, and the next line will never ICE. If the return type is an RPITIT, we shouldn't be calling associated_item on it, since that'll ICE.
When I mentioned that it should be more robust, I wasn't saying it was incomplete, I just don't really like that we have to treat associated items and RPITITs differently here (but this is a consequence of how they're currently implemented, and most code doesn't care about this distinction anyways).
|
@bors r+ |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#111861 (Don't ICE on return-type notation when promoting trait preds to associated type bounds) - rust-lang#111864 (Always require closure parameters to be `Sized`) - rust-lang#111870 (Rename `traits_in_crate` query to `traits`) - rust-lang#111880 (Don't ICE when computing PointerLike trait when region vars are in param-env) - rust-lang#111887 (Add regression tests for pretty-printing inherent projections) r? `@ghost` `@rustbot` modify labels: rollup
Fixes #111846