Unsoundness related to implied bounds for return types

[scalexm]

The following code compiles and is unsound:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=fc4210fcb8ba91c1ae883cd20deb2279

I believe this is due to the fact that we compute implied bounds for return types? Ironically, I did write about this some months ago, as a reminder to myself for the implementation of the implied bounds RFC:

https://gist.github.com/scalexm/cf32cea831a5d8193fa8a484099b71a2

I wasn’t aware this bug was actually existing in Rust already.

cc @nikomatsakis

[matthewjasper]

Only an issue on 2018 edition. Probably NLL.

[scalexm]

@matthewjasper Ah right I didn’t notice. This may make investigations easier.
What bugs me is the fact that y‘s type seems not to be WF-checked when declared.

[matthewjasper]

Variable types aren't WF-checked in NLL. We should include the output type here:

rust/src/librustc_mir/borrow_check/nll/type_check/mod.rs

Line 1455 in d370493

sig.inputs().iter().map(|ty| ty::Predicate::WellFormed(ty)),

[scalexm]

Variable types aren't WF-checked in NLL. We should include the output type here:

rust/src/librustc_mir/borrow_check/nll/type_check/mod.rs
Line 1455 in d370493
sig.inputs().iter().map(|ty| ty::Predicate::WellFormed(ty)),

Indeed, that works :) Care to make a PR? I won’t be able to do it myself today.

I’ve not been able to weaponize my code snippet with this fix (or with the 2015 edition); however I believe this is because currently, when you have fn(...) -> S<T> as an input type, like in:

fn call<'a, T>(x: &'a T, f: fn(&'a T) -> S<&'a T>) {
    let y = f(x);
}

then you consider S<&'a T> to be an input type as well, hence you have an implied &'a T: 'static bound preventing the kind of weaponization that I described in my gist.

But when we designed implied bounds with @nikomatsakis, we thought that function pointers would be seen only in a « shallow » way, i.e. we would not consider the types appearing in the function pointer as input types, so that we don’t get any implied bounds from them.

Regarding the fact that we currently do have implied bounds for return types, coupled with my gist above, I think we may want to reconsider either the WF-ness of function pointers in the implied bounds setting, or the computation of implied bounds for return types (but removing it would be a breaking change).

[nikomatsakis]

I've always regretted that output types are used for WF purposes, but I don't know how to fix it without breakage.

Still @scalexm we should definitely revisit the definition and make sure we get this straight. We also have to think about the interaction of variance (#25860). I've been assuming that as we transition more towards chalk, we would be able to solve the soundness hole by encoding the "implied bounds" for a fn into the for binder on the fn type -- so e.g. the type might be for<'a> where ('a: 'static) fn(...) -> ... The basic idea is that variance only becomes a factor once we get to the fn pointer type. But I feel like there are enough subtle points here that we really have to sit down again and go over everything (particularly since the implied bounds proposal itself went through so many revisions).