impl Trait is allowed in the return type of main

[leoyvens]

we’re stabilizing the combination of features that allows you to put impl Trait in the return type of main as in fn main() -> impl Copy {}. Amusing but unintended so it’s better to forbid this for now.

[cuviper]

It's a bit late to change this. Does it cause any problem? AFAICT it just gives you a weird way to declare main, but no new capability.

[leoyvens]

It doesn't give any new capability, I guess impl Termination would even make sense in the return type of main. This bug could be considered a feature.

[pietroalbini]

cc @rust-lang/compiler @Mark-Simulacrum

[earthengine]

Why this is an issue? main returns () and () implements Copy.

[Zoxc]

impl Copy does not implement Termination, which is required for the return type of main.

[oli-obk]

Yea, it seems you can use any trait:





trait Goo {}
impl Goo for () {}
fn main() -> impl Goo {}

Works on beta and nightly. So it'll probably work on this weeks stable

You can't do anything stupid with this feature. The checks see right through the impl Trait to the real type (http://play.rust-lang.org/?gist=243499b4b1e837bc41905ac814bb9a4b&version=nightly&mode=debug). I'd say adding a regression test that ensures that this corner case essentially ignores the anonymization of impl Trait is fine. We can add a deny by default lint that tells you that while this works, it's not pretty.

[Mark-Simulacrum]

This seems fine to me and unless we care enough to stop the stable release we're not going to change this. cc @rust-lang/lang though.

[nikomatsakis]

Hmm, I feel like we should just fix this. I doubt there are a lot of people taking advantage of it. I can put up some mentoring instructions. We can do a warning period if needed.

[leoyvens]

Fwiw I tried fixing by doing this and got ICEs and stack oveflows which I couldn't debug so I gave up.

[nikomatsakis]

@leodasvacas

Fwiw I tried fixed this doing this and got ICEs and stack oveflows which I couldn't debug so I gave up.

Hmm, I don't understand the stack overflows, but I think I would expect that patch to have no effect. The cause of the bug is that we are "instantiating" the impl Trait, here:

rust/src/librustc_typeck/check/mod.rs

Line 1041 in 57dc984

let ret_ty = fcx.instantiate_anon_types_from_return_value(fn_id, &ret_ty);

In the process, we shadow the "original" ret_ty with a new variable ret_ty. This new ret_ty will contain an inference variable used to find the "hidden" type underneath the impl Trait.

Later on, when we add the obligation that R: Terminate (where R is the return type), we use this new ret_ty variable:

rust/src/librustc_typeck/check/mod.rs

Line 1135 in 57dc984

let substs = fcx.tcx.mk_substs(iter::once(Kind::from(ret_ty)));

If we used the original (currently shadowed) ret_ty, I think it would permit you to use -> impl Terminate but not other impl traits.

(That said, it wouldn't be the end of the world if we just let this go, I suppose.)

[pietroalbini]

As far as I understand we don't want to block 1.26 stable on this, right? In that case I think we should go with a lint instead of an hard error, since both of the features will be stabilized tomorrow now.

[leoyvens]

@nikomatsakis I probably borked the state of my clone or something. Thanks for the explanation, makes perfect sense, will make a patch.