`check-cfg` tests are prone to merge conflicts

[jyn514]

Right now, the tests in tests/ui/check-cfg/ contain every built-in config known to the compiler, like so:

rust/tests/ui/check-cfg/allow-same-level.stderr

Line 7 in 061ee95

= help: expected names are: `clippy`, `debug_assertions`, `doc`, `doctest`, `fmt_debug`, `miri`, `overflow_checks`, `panic`, `proc_macro`, `relocation_model`, `rustfmt`, `sanitize`, `sanitizer_cfi_generalize_pointers`, `sanitizer_cfi_normalize_integers`, `target_abi`, `target_arch`, `target_endian`, `target_env`, `target_family`, `target_feature`, `target_has_atomic`, `target_has_atomic_equal_alignment`, `target_has_atomic_load_store`, `target_os`, `target_pointer_width`, `target_thread_local`, `target_vendor`, `ub_checks`, `unix`, and `windows`

this means they have to be updated each time a new builtin cfg is added, which is annoying, prone to merge conflicts, and distracts from what the test is actually doing. Also, it's just not a very good diagnostic? If you name a check-cfg something the compiler doesn't know, an exhaustive list of things it does know is probably not the thing you want.

I suggest one or more of the following:

• Add a limit for the number of cfgs we will suggest at once, and change the diagnostic to say "... and N more cfgs" when it truncates. That would go around here:

  rust/compiler/rustc_lint/src/early/diagnostics/check_cfg.rs

  Line 143 in 061ee95

  Some(lints::unexpected_cfg_name::ExpectedValues { best_match, possibilities })

  and here:

  rust/compiler/rustc_lint/src/early/diagnostics/check_cfg.rs

  Line 206 in 061ee95

  possibilities: possibilities.into(),

• Normalize the output so we don't actually see the builtin cfg itself, just the diagnostic around it.

@rustbot label A-testsuite A-diagnostics F-check-cfg

[jieyouxu]

cc @Urgau do you have any preferences for this?

[Urgau]

I prefer if we normalize the output, it's irrelevant for the test.

I had a few sparse minutes and did it my-self in #136016.

[Urgau]

Also, it's just not a very good diagnostic? If you name a check-cfg something the compiler doesn't know, an exhaustive list of things it does know is probably not the thing you want.

When I ported some code base as part the stabilization effort, having that list was helpful for the custom cfgs.

It should also be noted that the list is only printed once (always the first warning) as to reduce the visual impact.

[Urgau]

Add a limit for the number of cfgs we will suggest at once

Btw, we already have a limit, it's currently 35.

rust/compiler/rustc_lint/src/early/diagnostics/check_cfg.rs

Line 11 in 061ee95

const MAX_CHECK_CFG_NAMES_OR_VALUES: usize = 35;