Skip to content

rustc doesn't check nested WFness if it's in a higher-ranked predicate #104

Open
@compiler-errors

Description

@compiler-errors
Member

rust-lang/rust#122501 (comment)

This will probably end up complicating implied bounds computation in binders?

Activity

compiler-errors

compiler-errors commented on Apr 8, 2024

@compiler-errors
MemberAuthor

Minimal I think:

trait Bound {}

struct W<'a, T: Bound>(&'a T);

fn wf<T>() where for<'a> W<'a, T>: Sized {}

We should recurse on W<'a, T> and see T: Bound must hold, but we don't even recurse on the self arg of the predicate because the trait has escaping bound vars.

jackh726

jackh726 commented on Apr 11, 2024

@jackh726
Member

That regression list sucks. I think this is something we should consider slowly moving towards error (or at least deny-by-default) by starting with a warn-by-default lint.

I'm also curious if there's a good MCVE for things that are so "obvious" as the example above. This modification, for example, is pretty clear what the problem is when trying to call wf:

use std::fmt::Debug;

trait Bound {}

struct W<'a, T: Bound>(&'a T);

fn wf<T>() where for<'a> W<'a, T>: Debug {}

fn main() {
    wf::<u32>();
}

But, I could imagine that we can have move subtle things we don't check in e.g. super trait bounds. These could be good candidates to also move towards erroring quicker.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @compiler-errors@jackh726

        Issue actions

          rustc doesn't check nested WFness if it's in a higher-ranked predicate · Issue #104 · rust-lang/trait-system-refactor-initiative