Fix incorrect cfg structured suggestion and make suggestion verbose

[estebank]

Keep a span for the attribute within the square brackets as part of the AttrKind.

error: `cfg` is not followed by parentheses
  --> $DIR/cfg-attr-syntax-validation.rs:4:1
   |
LL | #[cfg = 10]
   | ^^^^^^^^^^^
   |
help: expected syntax is
   |
LL - #[cfg = 10]
LL + #[cfg(/* predicate */)]
   |

Noticed in #137343 (comment).

[rustbot]

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[oli-obk]

I'll give it another review after the duplicate arg function is duplicating it internally. I can't tell what else is simplifyable without checking out the PR locally and playing with it

[oli-obk]

Maybe keep the value? Seems like often ppl may have written #[cfg = "linux"]

[estebank]

We should do that only if we are certain that the value is a valid flag.

[oli-obk]

The user provided input, why would we just overwrite it with a comment?

[estebank]

The predicates can only be either bare identifiers or ident = lit.

If they write #[cfg = ident] they get

error: attribute value must be a literal
  --> $DIR/cfg-attr-syntax-validation.rs:28:9
   |
LL | #[cfg = a]
   |         ^

which is a separate error.

If they write #[cfg = "linux"], then we have to inspect the literal and reverse map it to target_os so that we suggest #[cfg(target_os = "linux)]. If we don't do that, and someone writes #[cfg = "foo"] or #[cfg = true], what should we suggest other than the generic predicate? In those cases we should link to https://doc.rust-lang.org/reference/conditional-compilation.html#set-configuration-options, which is the most comprehensive explanation of what is valid there (even though I don't like linking to the reference if there are more newbie friendly documents, which we don't seem to have for cfg). If we keep that reverse mapping, does that mean we also have to dynamically create the reverse mapping for all features in the current crate as well?

Note that I am not against doing any of that, it's just that this PR was to fix the incorrect suggestion, which needs to happen regardless of additional logic to make the suggestion more comprehensive.

[oli-obk]

Pls add docs with examples what it refers to

[oli-obk]

I think no caller needs this to be different as there are no args

[rustbot]

Some changes occurred in compiler/rustc_builtin_macros/src/autodiff.rs

cc @ZuseZ4

[rust-log-analyzer]

The job pr-check-2 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[RUSTC-TIMING] askama test:false 0.164
error[E0061]: this function takes 3 arguments but 2 arguments were supplied
    --> src/librustdoc/clean/types.rs:1075:54
     |
1075 |                     item.meta_item().and_then(|item| rustc_expand::config::parse_cfg(item, sess))
     |                                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^------------ argument #3 of type `rustc_span::Span` is missing
     |
note: function defined here
    --> /checkout/compiler/rustc_expand/src/config.rs:473:8
     |
473  | pub fn parse_cfg<'a>(
     |        ^^^^^^^^^
help: provide the argument
     |
1075 |                     item.meta_item().and_then(|item| rustc_expand::config::parse_cfg(item, sess, /* rustc_span::Span */))
     |                                                                                                ++++++++++++++++++++++++

For more information about this error, try `rustc --explain E0061`.
[RUSTC-TIMING] rustdoc test:false 3.069
error: could not compile `rustdoc` (lib) due to 1 previous error

[bors]

☔ The latest upstream changes (presumably #143460) made this pull request unmergeable. Please resolve the merge conflicts.