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

Minor syntax errors in async functions give a wall of unrelated "the future is not Send" errors #119678

Closed
jamesmunns opened this issue Jan 7, 2024 · 6 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jamesmunns
Copy link
Member

jamesmunns commented Jan 7, 2024

Code

Inside of an async function, make some kind of syntax error, like calling a function that doesn't exist or was not yet imported.

Current output

This produces a very large amount of output:

    Checking flippy v0.1.0 (/Users/james/personal/erdnuss/host/flippy)
error[E0425]: cannot find function `esteban` in this scope
   --> src/dom_worker.rs:102:13
    |
102 |             esteban();
    |             ^^^^^^^ not found in this scope

error: future cannot be sent between threads safely
   --> src/client.rs:160:49
    |
160 | ...k::spawn(runtil(ctxt.clone(), wrx, device)),
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ future returned by `runtil` is not `Send`
    |
note: opaque type is declared here
   --> src/dom_worker.rs:90:7
    |
90  |     ) {
    |       ^
note: this item depends on auto traits of the hidden type, but may also be registering the hidden type. This is not supported right now. You can try moving the opaque type and the item that actually registers a hidden type into a new submodule
   --> src/client.rs:139:10
    |
139 | async fn watch_devices(ctxt: Arc<Context>) {
    |          ^^^^^^^^^^^^^
note: future is not `Send` as this value is used across an await
   --> src/dom_worker.rs:217:9
    |
214 |           let incoming = self.incoming(&mut biq, mac, tx, &...
    |               -------- has type `impl Future<Output = ()>` which is not `Send`
...
217 | /         select! {
218 | |             _ = incoming => {
219 | |                 tracing::info!(
220 | |                     dom_short = self.dev.short,
...   |
235 | |             }
236 | |         };
    | |_________^ await occurs here, with `incoming` maybe used later
...
245 |       }
    |       - `incoming` is later dropped here
note: required by a bound in `tokio::spawn`
   --> /Users/james/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/task/spawn.rs:166:21
    |
164 |     pub fn spawn<F>(future: F) -> JoinHandle<F::Output>
    |            ----- required by a bound in this function
165 |     where
166 |         F: Future + Send + 'static,
    |                     ^^^^ required by this bound in `spawn`
    = note: this error originates in the macro `$crate::select` which comes from the expansion of the macro `select` (in Nightly builds, run with -Z macro-backtrace for more info)

error: cannot check whether the hidden type of opaque type satisfies auto traits
   --> src/client.rs:34:28
    |
34  |         tokio::task::spawn(watch_devices(ctxt.clone()));
    |         ------------------ ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |         |
    |         required by a bound introduced by this call
    |
note: opaque type is declared here
   --> src/client.rs:139:44
    |
139 | async fn watch_devices(ctxt: Arc<Context>) {
    |                                            ^
note: this item depends on auto traits of the hidden type, but may also be registering the hidden type. This is not supported right now. You can try moving the opaque type and the item that actually registers a hidden type into a new submodule
   --> src/client.rs:29:12
    |
29  |     pub fn new() -> Option<Self> {
    |            ^^^
note: required by a bound in `tokio::spawn`
   --> /Users/james/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.1/src/task/spawn.rs:166:21
    |
164 |     pub fn spawn<F>(future: F) -> JoinHandle<F::Output>
    |            ----- required by a bound in this function
165 |     where
166 |         F: Future + Send + 'static,
    |                     ^^^^ required by this bound in `spawn`

For more information about this error, try `rustc --explain E0425`.
error: could not compile `flippy` (bin "flippy") due to 3 previous errors

In particular in the console, ONLY the first error is useful, the rest is just noise.

Desired output

Just the first error, please:

error[E0425]: cannot find function `esteban` in this scope
   --> src/dom_worker.rs:102:13
    |
102 |             esteban();
    |             ^^^^^^^ not found in this scope

Rationale and extra context

Screenshot 2024-01-07 at 02 35 49

This is what it looks like graphically, at the moment.

Other cases

No response

Anything else?

No response

@jamesmunns jamesmunns added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 7, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jan 7, 2024
@compiler-errors
Copy link
Member

Are you using the most up to date rustc? Additionally, does this reproduce on nightly?

@jamesmunns
Copy link
Member Author

jamesmunns commented Jan 7, 2024

This was produced on:

active toolchain
----------------

stable-aarch64-apple-darwin (default)
rustc 1.73.0 (cc66ad468 2023-10-03)

Will try updated version + nightly, please hold...

@compiler-errors
Copy link
Member

Can you share any code to reproduce this? I don't think we can do very much without some code to test.

@compiler-errors
Copy link
Member

compiler-errors commented Jan 7, 2024

This may have been fixed by #115294, which is only present >= 1.74

@jamesmunns
Copy link
Member Author

This isn't in a public project, but I feel like I've hit this before. Let me see if 1.75 fixes it.

@jamesmunns
Copy link
Member Author

Oh. Yeah, it's perfect in 1.75 :)

    Checking flippy v0.1.0 (/Users/james/personal/erdnuss/host/flippy)
error[E0425]: cannot find function `esteban` in this scope
   --> src/dom_worker.rs:102:13
    |
102 |             esteban();
    |             ^^^^^^^ not found in this scope

For more information about this error, try `rustc --explain E0425`.
error: could not compile `flippy` (bin "flippy") due to previous error

I'll go ahead and close, sorry for the noise and thanks for the reminder to update :)

compiler-errors added a commit to compiler-errors/rust that referenced this issue Jan 7, 2024
…=Mark-Simulacrum

Ask for rustc version in diagnostic reports, remind users to update their toolchain

IDK why we don't ask for rustc toolchain when filing diagnostic issues. Diagnostics are sometimes very dramatically affected by compiler version, and users may report old diagnostic issues that were fixed by subsequent rustc versions that they have yet to update to.

For example, rust-lang#119678 was made a bit more difficult to triage due to the template not asking the issuer to report their rustc version.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jan 7, 2024
Rollup merge of rust-lang#119679 - compiler-errors:issue-templates, r=Mark-Simulacrum

Ask for rustc version in diagnostic reports, remind users to update their toolchain

IDK why we don't ask for rustc toolchain when filing diagnostic issues. Diagnostics are sometimes very dramatically affected by compiler version, and users may report old diagnostic issues that were fixed by subsequent rustc versions that they have yet to update to.

For example, rust-lang#119678 was made a bit more difficult to triage due to the template not asking the issuer to report their rustc version.
@fmease fmease closed this as not planned Won't fix, can't repro, duplicate, stale Jan 16, 2024
@fmease fmease removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jan 16, 2024
@fmease fmease closed this as completed Jan 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants