3

Don't consider generic args of supertrait in `deref_into_dyn_supertrait` lint b...

 6 months ago
source link: https://github.com/rust-lang/rust/pull/118026
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Conversation

Member

I actually wonder if we should just warn on any deref impl with a target type that matches a supertrait by def-id.

cc #89460

r? types

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

Nov 17, 2023

Contributor

I think matching super trait by DefId feels appropriate 🤔 feels like it should also be possible to cause inference breakage that way

Contributor

example breakage with trait_upcasting when sharing the same DefId

#![deny(deref_into_dyn_supertrait)]
#![feature(trait_upcasting)] // remove this and the test compiles
use std::ops::Deref;

trait Bar<T> {}
impl<T, U> Bar<U> for T {}

trait Foo: Bar<i32> {
    fn as_dyn_bar_u32<'a>(&self) -> &(dyn Bar<u32> + 'a);
}

impl Foo for () {
    fn as_dyn_bar_u32<'a>(&self) -> &(dyn Bar<u32> + 'a) {
        self
    }
}

impl<'a> Deref for dyn Foo + 'a {
    //~^ ERROR `dyn Foo` implements `Deref<Target = dyn Bar<u32>>` which conflicts with supertrait `Bar<i32>`
    //~| WARN this was previously accepted by the compiler
    type Target = dyn Bar<u32> + 'a;

    fn deref(&self) -> &Self::Target {
        self.as_dyn_bar_u32()
    }
}

fn take_dyn<T>(x: &dyn Bar<T>) -> T {
    todo!()
}

fn main() {
    let x: &dyn Foo = &();
    let y = take_dyn(x);
    let z: u32 = y;
}

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK