Skip to content

Import suggestions misplaced when beginning of file is #[tokio::main] #89810

New issue

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

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

Already on GitHub? # to your account

Closed
scrabsha opened this issue Oct 12, 2021 · 4 comments
Closed

Import suggestions misplaced when beginning of file is #[tokio::main] #89810

scrabsha opened this issue Oct 12, 2021 · 4 comments
Assignees
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

@scrabsha
Copy link
Contributor

Given the following code:

#[tokio::main]
async fn main() {
    let _: PathBuf = todo!();
}

(playground link)

The current output is:

   Compiling playground v0.0.1 (/playground)
error[E0412]: cannot find type `PathBuf` in this scope
 --> src/main.rs:3:12
  |
3 |     let _: PathBuf = todo!();
  |            ^^^^^^^ not found in this scope
  |
help: consider importing this struct
  |
2 | async use std::path::PathBuf;
  |       +++++++++++++++++++++++

For more information about this error, try `rustc --explain E0412`.
error: could not compile `playground` due to previous error

async imports look cool tbh, but that's not valid Rust.
This happens on stable, beta and nightly.

Ideally the use std::path::PathBuf should be placed in line 1 and before the async keyword.

I tried to keep the issue title and description super specific to this situation as I don't have time to investigate with other macros. Feel free to report similar problems so that I can make it more general.

@scrabsha scrabsha 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 Oct 12, 2021
@oli-obk oli-obk self-assigned this Oct 12, 2021
@oli-obk
Copy link
Contributor

oli-obk commented Oct 12, 2021

oh no XD macros strike again... I thought I had handled them in general, but obviously not.

@ehuss
Copy link
Contributor

ehuss commented Oct 12, 2021

I think this is a duplicate of #86241 which has some comments on why this happens.

@oli-obk I think this issue was known when this was added in #44215. The UsePlacementFinder is unable to deal with active attributes since they are removed from the AST, and the span information is lost. There is a fixme for it here and here.

Recently, macros have been added to the HIR in #88019. I'm not sure if that helps, but I think would be a start into maybe investigating.

EDIT: nevermind, I forgot that #88019 is for the macro_rules definitions, not the invocations.

@gamozolabs
Copy link

Also related #87613.

@oli-obk
Copy link
Contributor

oli-obk commented Jul 7, 2022

This has been resolved

@oli-obk oli-obk closed this as completed Jul 7, 2022
# for free to join this conversation on GitHub. Already have an account? # 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