Type mismatch with async block to dyn Future coercion

[Veykril]

use core::future::Future;
use core::pin::Pin;

// expected Pin<Box<dyn Future<Output = ()> + Send, Global>>, found Pin<Box<impl Future<Output = ()>, Global>>
fn send() -> Pin<Box<dyn Future<Output = ()> + Send + 'static>> {
    Box::pin(async move {})
}

// expected Pin<Box<dyn Future<Output = ()>, Global>>, found Pin<Box<impl Future<Output = ()>, Global>>
fn not_send() -> Pin<Box<dyn Future<Output = ()> + 'static>> {
    Box::pin(async move {})
}

high priority as this affects all uses of async_trait

[kpreid]

Possibly-the-same-bug appears without async and Future: this code

fn foo() {
    let a = noise::Value::new();
    let b: noise::ScaleBias<'_, [f64; 2]> = noise::ScaleBias::new(&a).set_bias(1.0);
}

(with noise = "0.7.0") produces the false error expected &dyn NoiseFn<[f64; 2]>, found &Value. I haven't found a way to reproduce it with a simple locally-defined trait, though.

[Emilgardis]

is there a way to locally disable the check for cases where this hits?

[lnicola]

@Emilgardis not right now. Only per-project.

[BlackDex]

Isn't this fixed already?
The current latest nightly version works for me without any issues.

[flodiebold]

The error mentioned in the issue is still showing up, and so is the noise error.

[arilotter]

Any pointers on getting started on this bug? It's a major blocker for my Rust development use case - I can't use RA at all for work until this is fixed, and have to rely on cargo watch. Would love to help fix it.

[lnicola]

@arilotter this diagnostic is opt-in in newer RA versions.

[kpreid]

@lnicola Where is that controlled? I'm still getting the false error and I've checked my user and workspace VSCode settings.json for rust-analyzer settings that sound related to this, and I don't see any.

[flodiebold]

It's rust-analyzer.diagnostics.enableExperimental.

[kpreid]

I don't have that setting enabled. I'm on r-a extension v0.2.1040 server 5dce1ff02 2022-05-02 stable, and my settings files contain only the following r-a settings:

{
    "rust-analyzer.inlayHints.parameterHints": false,
    "rust-analyzer.inlayHints.maxLength": 5,
    "rust-analyzer.inlayHints.typeHints": false,
    "rust-analyzer.diagnostics.disabled": [
        "missing-unsafe"
    ],
    "rust-analyzer.inlayHints.enable": false
}

{
    "rust-analyzer.cargo.allFeatures": true,
    "rust-analyzer.assist.importPrefix": "crate",
    "rust-analyzer.checkOnSave.command": "clippy",
    "rust-analyzer.checkOnSave.allTargets": true,
    "rust-analyzer.assist.importGranularity": "module"
}

[arilotter]

rust-analyzer.diagnostics.enableExperimental was on by default for me.

[kpreid]

The VS Code settings UI thinks it is off by default, and editing the setting to be either explicitly true or explicitly false made no difference.

[flodiebold]

Any pointers on getting started on this bug? Would love to help fix it.

I think the basic problem here is that currently, we just model async blocks as an opaque type, and we don't implement any logic for the hidden type behind the opaque type:

rust-analyzer/crates/hir-ty/src/chalk_db.rs

Lines 282 to 285 in 1f709d5

	fn hidden_opaque_type(&self, _id: chalk_ir::OpaqueTyId<Interner>) -> chalk_ir::Ty<Interner> {
	// FIXME: actually provide the hidden type; it is relevant for auto traits
	TyKind::Error.intern(Interner)
	}

As the FIXME says, the hidden type is used to determine auto traits, and this is probably the reason Chalk says the coercion doesn't work because it doesn't implement Send.
To really properly handle this, we'd need to desugar the async block to a generator like rustc does, and actually implement generators. Or at least give it some generator type, and make sure the generator type implements all necessary auto traits somehow. Alternatively we could do some hack to consider these opaque types to always implement auto traits, though I'm not sure what the best way to do this is.

[flodiebold]

This is fixed.