closures accept ill-formed inputs

[aliemjay]

Both of these closures should fail borrowck: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=e9855ecda2f9427454cebce7738e598d

struct MyTy<T: Trait>(T);
trait Trait {}
impl Trait for &'static str {}
fn wf<T>(_: T) {}

fn test() {
    let _: for<'x> fn(MyTy<&'x str>) = |_| {}; // PASS!
    
    // but it should fail for the same reason this fails:
    let _: for<'x> fn(MyTy<&'x str>) = |x| wf(x); // FAIL
}

I think we should simply do WF-checking of closure input/output types in the closure environment, but doing so would cause accidental breakages due to #104477. So #104477 should be resolved first.

@rustbot label A-NLL NLL-sound C-bug T-types A-borrow-checker

[aliemjay]

This is not exclusive to borrowck - typeck can also ignore the well-formedness of cloure args:

struct Iter<T: Iterator>(T);

fn foo(_: impl Fn(&Iter<u8>)) {}

fn main() {
    foo(|_| {});
}

edit: this has been fixed in #123531

[lcnr]

cc @LorrensP-2158466 would you like to look into this issue? I expect this to now be doable once our improvements to closure constraint propagation lands

[LorrensP-2158466]

Yeah sure! I'll see what I can do, but I won't assign it to me just yet.

[LorrensP-2158466]

Right, I wanna take this on. Some questions before i dive in:

• what is WF-checking? I can't find anything concrete in the dev-guide.
• What is the relevant code? I have a feeling it's primarly in compiler/rustc_hir_analysis/src/hir_wf_check.rs, but maybe somewhere else?
• Explain to me why this shouldn't be accepted? When can this be a problem? I think it will be easier to fix this if I actually understand what's going wrong.

@rustbot claim

[lcnr]

what is WF-checking? I can't find anything concrete in the dev-guide.

we should add something about that 😁

WF-checking is making sure that "types and item definitions make sense", where "makes sense" means "whatever is necessary for the rest of the type system to work properly".

There are three different things generally called wf-checking:

• proving WellFormed obligations in the trait solver, checks specific types to be well-formed
• adding WellFormed obligations for stuff during typeck and borrowck to make sure they're wf
• checking that items are well-formed, in wf_check, this emits WellFormed obligations, but also does a bunch of additional cehcks

What is the relevant code? I have a feeling it's primarly in compiler/rustc_hir_analysis/src/hir_wf_check.rs, but maybe somewhere else?

HIR wf check is a diagnostics only thing that tries to point to a more specific span. We should make that more explicit in that module. Would u be open to add an explicit comment to that effect to either the module itself or the function?

This check should happen in MIR typeck. Somewhere early on we should add checks that all closure arguments are wf while checking the closure itself.

Explain to me why this shouldn't be accepted? When can this be a problem? I think it will be easier to fix this if I actually understand what's going wrong.

Because the type MyType<'a> only "makes sense" if 'a is equal to 'static. In the PR example, you can see that using the closure argument already emits an error, it's only when the argument is not used inside of the closure that we don't check its type

[theemathas]

WF also isn't checked for dyn. The below code compiles:

trait Trait {}
trait Weird<T: Trait> {}
fn f1(_: Box<dyn Weird<i32>>) {}