|
| 1 | +// aux-build:amputate-span.rs |
| 2 | +// run-rustfix |
| 3 | +// edition:2018 |
| 4 | +// compile-flags: --extern amputate_span |
| 5 | + |
| 6 | +// This test has been crafted to ensure the following things: |
| 7 | +// |
| 8 | +// 1. There's a resolution error that prompts the compiler to suggest |
| 9 | +// adding a `use` item. |
| 10 | +// |
| 11 | +// 2. There are no `use` or `extern crate` items in the source |
| 12 | +// code. In fact, there is only one item, the `fn main` |
| 13 | +// declaration. |
| 14 | +// |
| 15 | +// 3. The single `fn main` declaration has an attribute attached to it |
| 16 | +// that just deletes the first token from the given item. |
| 17 | +// |
| 18 | +// You need all of these conditions to hold in order to replicate the |
| 19 | +// scenario that yielded issue 87613, where the compiler's suggestion |
| 20 | +// looks like: |
| 21 | +// |
| 22 | +// ``` |
| 23 | +// help: consider importing this struct |
| 24 | +// | |
| 25 | +// 47 | hey */ async use std::process::Command; |
| 26 | +// | ++++++++++++++++++++++++++ |
| 27 | +// ``` |
| 28 | +// |
| 29 | +// The first condition is necessary to force the compiler issue a |
| 30 | +// suggestion. The second condition is necessary to force the |
| 31 | +// suggestion to be issued at a span associated with the sole |
| 32 | +// `fn`-item of this crate. The third condition is necessary in order |
| 33 | +// to yield the weird state where the associated span of the `fn`-item |
| 34 | +// does not actually cover all of the original source code of the |
| 35 | +// `fn`-item (which is why we are calling it an "amputated" span |
| 36 | +// here). |
| 37 | +// |
| 38 | +// Note that satisfying conditions 2 and 3 requires the use of the |
| 39 | +// `--extern` compile flag. |
| 40 | +// |
| 41 | +// You might ask yourself: What code would do such a thing? The |
| 42 | +// answer is: the #[tokio::main] attribute does *exactly* this (as |
| 43 | +// well as injecting some other code into the `fn main` that it |
| 44 | +// constructs). |
| 45 | + |
| 46 | +use std::process::Command; |
| 47 | + |
| 48 | +#[amputate_span::drop_first_token] |
| 49 | +/* what the |
| 50 | +hey */ async fn main() { |
| 51 | + Command::new("git"); //~ ERROR [E0433] |
| 52 | +} |
| 53 | + |
| 54 | +// (The /* ... */ comment in the above is not part of the original |
| 55 | +// bug. It is just meant to illustrate one particular facet of the |
| 56 | +// original non-ideal behavior, where we were transcribing the |
| 57 | +// trailing comment as part of the emitted suggestion, for better or |
| 58 | +// for worse.) |
| 59 | + |
| 60 | +#[allow(dead_code)] |
| 61 | +mod inner { |
| 62 | + use std::process::Command; |
| 63 | + |
| 64 | +#[amputate_span::drop_first_token] |
| 65 | + /* another interesting |
| 66 | + case */ async fn foo() { |
| 67 | + Command::new("git"); //~ ERROR [E0433] |
| 68 | + } |
| 69 | +} |
0 commit comments