Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusing/incorrect error message with incoherent implementations and async blocks #67651

Open
syntacticsugarglider opened this issue Dec 27, 2019 · 7 comments

Comments

@syntacticsugarglider
Copy link

@syntacticsugarglider syntacticsugarglider commented Dec 27, 2019

use std::future::Future;

pub trait Bound {}

pub struct Error;

impl Bound for Error {}

pub struct Wrap;

impl<T: Bound> From<T> for Wrap {
    fn from(input: T) -> Self {
        Wrap
    }
}

impl<T: Into<Wrap>> From<T> for Error {
    fn from(input: T) -> Self {
        Error
    }
}

fn fail() -> impl Future<Output = Result<(), Error>> {
    async move {
        let a: Result<(), Error> = Ok(());
        let a: () = a?;
        Ok(())
    }
}

This fails with type annotations required: cannot resolve Error: std::convert::From<Error> (E0283) instead of the expected conflicting implementations of trait std::convert::From<Error> for type Error (E0119). Changing fail to

fn fail() -> Result<(), Error> {
    let a: Result<(), Error> = Ok(());
    let a: () = a?;
    Ok(())
}

i.e. eliminating the async block leads to the expected error message being produced.

playground demonstration

@tmandry

This comment has been minimized.

Copy link
Contributor

@tmandry tmandry commented Jan 7, 2020

@Centril said they'd look into minimizing this further.

@tmandry

This comment has been minimized.

Copy link
Contributor

@tmandry tmandry commented Jan 7, 2020

Also assigning @nikomatsakis to look into this along with #66312.

@Centril

This comment has been minimized.

Copy link
Member

@Centril Centril commented Jan 7, 2020

Reduced:

trait From {
    fn from();
}

impl From for () {
    fn from() {}
}

impl From for () {
    fn from() {}
}

fn af() -> impl core::future::Future<Output = ()> {
    async move { From::from() }
}

/*
fn f() -> () {
    From::from()
}
*/
@Centril Centril removed their assignment Jan 7, 2020
@nikomatsakis

This comment has been minimized.

Copy link
Contributor

@nikomatsakis nikomatsakis commented Jan 8, 2020

I've been investigating this. I'm not sure I understand yet what is going on, but I'm going to leave a few breadcrumbs as I go. To start, I think part of the problem lies on this line:

return tcx.typeck_tables_of(def_id).node_type(hir_id);

Specifically what is happening here is that we are executing the type_of query on a generator, and this is triggering us to do a full typeck. There is probably a good reason for this, but it's not generally how things are meant to work. This query is meant to be "modular", in that we can create the type for all items without type checking their bodies (this is possible because, for example, Rust requires us to fully specify the type signature for functions). I'm not quite sure why generators behave differently -- closures, for example, do not, as you can see if I give a bit more context:

Node::Expr(&hir::Expr { kind: hir::ExprKind::Closure(.., gen), .. }) => {
if gen.is_some() {
return tcx.typeck_tables_of(def_id).node_type(hir_id);
}
let substs = InternalSubsts::identity_for_item(tcx, def_id);
tcx.mk_closure(def_id, substs)
}

Here, on lines 1398-1399, you can see that for a closure we create a type with "identity substitutions", which means a closure type like Closure<P0...Pn> where Pi is a reference to a type parameter.

(I see that opaque types also behave differently; it seems like tcx.type_of(opaque) is used to fetch the concrete type of an opaque type. I actually think we should make that a distinct query, but I think it's neither here nor there.)

(I'm going to look a bit more at why generators behave this way now, not obvious to me that they must -- @Zoxc may have some details here?)

UPDATE: Based on some exploration of git history, this line goes way back to the original gen branch at least.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

@nikomatsakis nikomatsakis commented Jan 8, 2020

OK, I can confirm that the "naive fix" causes downstream errors, I haven't investigated those much yet:

@@ -1392,12 +1392,12 @@ fn type_of(tcx: TyCtxt<'_>, def_id: DefId) -> Ty<'_> {
         Node::Field(field) => icx.to_ty(&field.ty),

         Node::Expr(&hir::Expr { kind: hir::ExprKind::Closure(.., gen), .. }) => {
-            if gen.is_some() {
-                return tcx.typeck_tables_of(def_id).node_type(hir_id);
-            }
-
             let substs = InternalSubsts::identity_for_item(tcx, def_id);
-            tcx.mk_closure(def_id, substs)
+            if let Some(movability) = gen {
+                tcx.mk_generator(def_id, substs, movability)
+            } else {
+                tcx.mk_closure(def_id, substs)
+            }
         }

         Node::AnonConst(_) => {

I suspect they can be fixed though

@Zoxc

This comment has been minimized.

Copy link
Contributor

@Zoxc Zoxc commented Jan 8, 2020

@nikomatsakis Generator types contain the types of the values inside which are live across a yield statement, that is why typeck_tables_of is required there. We could move getting the interior type of the generator into a separate query, but that would only help if the problematic caller of type_of does not actually look at these.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

@nikomatsakis nikomatsakis commented Jan 13, 2020

@Zoxc I don't think that's sufficient reason by itself. Closure types also contain details that result from inference (e.g., the types that their upvars use), but type_of applied to a closure just gives you a fully generic type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.