Stream: wg-async-foundations

Topic: #62097


csmoe (Oct 23 2019 at 11:10, on Zulip):
error[E0178]: expected a path on the left-hand side of `+`, not `()`
 --> t.rs:2:17
  |
2 | fn foo<'a>() -> () +'a {}
  |                 ^^^^^^ expected a path

error[E0404]: expected trait, found builtin type `i32`
 --> t.rs:4:17
  |
4 | fn bar<'a>() -> i32 +'a {}
  |                 ^^^ not a trait

warning: trait objects without an explicit `dyn` are deprecated
 --> t.rs:4:17
  |
4 | fn bar<'a>() -> i32 +'a {}
  |                 ^^^^^^^ help: use `dyn`: `dyn i32 +'a`
  |
  = note: `#[warn(bare_trait_objects)]` on by default

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0178, E0404.
For more information about an error, try `rustc --explain E0178`.

error message differs with unit type at fn return. is this intended? cc @centril

centril (Oct 23 2019 at 11:44, on Zulip):

The error seems correct to me

csmoe (Oct 24 2019 at 13:24, on Zulip):

is there any workgroud to make this snippet work? I didn't find out anyway, so just stop suggesting on this case.
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a21601e91cb31a8d4d481f44d2c1c7a4
@nikomatsakis cc @davidtwco

davidtwco (Oct 24 2019 at 14:16, on Zulip):

I'm not aware of any, but I've not written a lot code using async/await so might not know.

davidtwco (Oct 24 2019 at 14:16, on Zulip):

Not suggesting seems like a reasonable resolution.

nikomatsakis (Oct 25 2019 at 18:43, on Zulip):

@csmoe I dont' think there is anything you can do to that function as written to make it compile, except either remove the where F: 'static bound on dummy_fn or else make the closure not capture self

nikomatsakis (Oct 25 2019 at 18:43, on Zulip):

definitely suggesting dummy_fn + '_ is... O_O

csmoe (Oct 30 2019 at 13:12, on Zulip):

@nikomatsakis

pub async fn run_dummy_fn(&self) {
        dummy_fn(|| self.some_fn()).await;
}

dose rustc desugar async fn run_dummy_fn()'s output? , desugaring_kind() is None in this case? (not sure whether this is expected or not)

nikomatsakis (Oct 30 2019 at 13:12, on Zulip):

seems like a bug

nikomatsakis (Oct 30 2019 at 13:13, on Zulip):

it certainly does desugar

nikomatsakis (Oct 30 2019 at 13:14, on Zulip):

the desugaring @csmoe is done by self.lower_async_fn_ret_ty in hir/lowering.rs

nikomatsakis (Oct 30 2019 at 13:14, on Zulip):

I think maybe the flaw in that function

nikomatsakis (Oct 30 2019 at 13:15, on Zulip):

ah yeah

nikomatsakis (Oct 30 2019 at 13:15, on Zulip):

@csmoe so on the final line of that function, there is:

nikomatsakis (Oct 30 2019 at 13:15, on Zulip):
        let opaque_ty_ref = hir::TyKind::Def(hir::ItemId { id: opaque_ty_id }, generic_args.into());

        hir::FunctionRetTy::Return(P(hir::Ty {
            kind: opaque_ty_ref,
            span,
            hir_id: self.next_id(),
        }))
nikomatsakis (Oct 30 2019 at 13:15, on Zulip):

I think it should be

nikomatsakis (Oct 30 2019 at 13:16, on Zulip):
        let opaque_ty_ref = hir::TyKind::Def(hir::ItemId { id: opaque_ty_id }, generic_args.into());

        hir::FunctionRetTy::Return(P(hir::Ty {
            kind: opaque_ty_ref,
            span: opaque_ty_span, // <-- changed this line!
            hir_id: self.next_id(),
        }))
nikomatsakis (Oct 30 2019 at 13:16, on Zulip):

cc @Taylor Cramer :point_up: do you agree with that?

nikomatsakis (Oct 30 2019 at 13:16, on Zulip):

in particular, this is creating the synthesized return type of -> Foo where Foo is a new opaque type

nikomatsakis (Oct 30 2019 at 13:16, on Zulip):

so we should be using a span marked with "compiler desugaring"

csmoe (Oct 30 2019 at 13:16, on Zulip):
        let opaque_ty_ref = hir::TyKind::Def(hir::ItemId { id: opaque_ty_id }, generic_args.into());

        hir::FunctionRetTy::Return(P(hir::Ty {
            kind: opaque_ty_ref,
            span: opaque_ty_span, // <-- changed this line!
            hir_id: self.next_id(),
        }))

thanks :heart:

Last update: Nov 18 2019 at 02:10UTC