Closed
Description
auto-reduced (treereduce-rust):
struct Wrapper<'rom>(T);
trait Foo {
fn bar() -> Wrapper<impl Sized>;
}
impl Foo for () {
fn bar() -> Wrapper<impl Sized>;
}
original:
struct Wrapper<'rom>(T);
//~^ ERROR cannot find type `T` in this scope
trait Foo {
fn bar() -> Wrapper<impl Sized>;
//~^ ERROR missing lifetime specifier
//~| ERROR struct takes 0 generic arguments but 1 generic argument was supplied
}
impl Foo for () {
fn bar() -> Wrapper<impl Sized>;
//~^ ERROR missing lifetime specifier
//~| ERROR struct takes 0 generic arguments but 1 generic argument was supplied
}
fn main() {}Version information
rustc 1.78.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.78.0-dev
LLVM version: 18.1.0
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Participants
Activity
matthiaskrgr commentedon Mar 17, 2024
Command:
/home/matthias/.rustup/toolchains/local-debug-assertions/bin/rustcProgram output
fmease commentedon Mar 17, 2024
Okay, lol, here the types obviously do unify and therefore #122172 isn't effective in this situation.
fmease commentedon Mar 17, 2024
More fundamentally, the thing that goes “wrong” in these kinds of situations is the fact that we call
collect_return_position_impl_trait_in_trait_tysif we haveopt_rpitit_infowhich is the case becauseassociated_type_for_impl_trait_in_implgenerated one because the HIR (!) type visitorRPITVisitorinsideassociated_types_for_impl_traits_in_associated_fnfound an opaque type in the HIR type (hereWrapper<impl Sized>) while the loweredrustc_middle::tytype (hereWrapper<'static>) no longer contains any opaque types ultimately leading to the assert triggering.In short:
Wrapper<impl Sized>, see an opaque type and take note of thatWrapper<'static>due to the argument kind mismatchI don't know if this
debug_assertis actually useful in general 🤔 What kinds of bugs is it supposed to catch?fmease commentedon Mar 17, 2024
cc @compiler-errors
fmease commentedon Mar 17, 2024
So either we delay the detection of RPITITs and the synthesis of RPITIT assoc tys until after HIR ty lowering / AstConv (but I don't know if that's an option) or we modify the assert (either remove it outright or check the corresp. HIR ty, I don't know if that makes sense; furthermore oli is/was on a roll to remove HIR operations from this part of the code base iirc).
compiler-errors commentedon Mar 18, 2024
@fmease: Yeah, this assertion was simply there to make sure we weren't incorrectly calling
collect_return_position_impl_trait_in_trait_tysfor methods that had no RPITITs themselves (b/c it's expensive, and it actually is a bit stronger in what it enforces in the method signatures since it useseqrather thansupin the signature relation for lifetime reasons), but now that this code isn't being changed much, I doubt that will ever happen. Feel free to remove it, or else I can do.fmease commentedon Mar 22, 2024
We could also delay a bug on mismatch 🤔
7 remaining items