Remove uses of cfg({any()/all()})

[clubby789]

This implements the followup warning suggested in rust-lang/rfcs#3695
Lint against an empty cfg(any/all), suggest the boolean literal equivalents.
#149791 (comment)

Tracking issue: #131204

[rustbot]

Some changes occurred in check-cfg diagnostics

cc @Urgau

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

[rustbot]

r? @chenyukang

rustbot has assigned @chenyukang.
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

[jdonszelmann]

r? jdonszelmann

[Urgau]

Can you split-off the FALSE -> false suggestion into it's own PR?

As for the warning it should probably be a lint (so it can be enabled and disabled), but either way the warning will need to go through T-lang first, with a nomination and maybe a crater run.

[joshtriplett]

With my T-lang hat on, this seems reasonable. Nominating for discussion of the new lint.

[clubby789]

Running into the above error where

    (@__items ($($not:meta,)*) ; ( ($($m:meta),*) ($($tokens:tt)*) ), $($rest:tt)*) => {
        #[cfg(all($($m,)* not(any($($not),*))))] cfg_if! { @__identity $($tokens)* }
        cfg_if! { @__items ($($not,)* $($m,)*) ; $($rest)* }
    };

is invoked with no $not, meaning we expand to not(any()) and raise the lint. Inclined to think that we should only lint for the literal any()/all() cases instead

[rustbot]

This PR modifies tests/ui/issues/. If this PR is adding new tests to tests/ui/issues/,
please refrain from doing so, and instead add it to more descriptive subdirectories.

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[clubby789]

Implemented as a pre-expansion early lint

[jdonszelmann]

Though I'm not T-lang, I agree with josh that this is a good lint to add. Just got some comments about the implementation but nothing too major. Just gotta clean some things up :)

View changes since this review

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[clubby789]

Moved back to an attribute lint as ignoring spans from expansions resolves the above issue, and addressed the other comments

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[clubby789]

Removed an overlapping case from Clippy

[jdonszelmann]

Alright, @rust-lang/lang r=me if you agree to accept this one

[jdonszelmann]

And ci passes haha

[rustbot]

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

The Miri subtree was changed

cc @rust-lang/miri

[ChayimFriedman2]

There is really no reason for the rust-analyzer changes, please revert them.

[clubby789]

My understanding was that the diagnostic changes would cause downstream failures; reverted 🙂

[ChayimFriedman2]

It's not real Rust code, it's a string used for testing and parsed by r-a.

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting.

We observed that applying this change would raise the MSRV of the code. Clippy has a mechanism for noting the MSRV of code and (optionally) not making suggestions that would raise it. rustc doesn't have that mechanism. We felt we didn't want to add this without such a mechanism.

(Separately, some folks felt that it should stay in clippy and not rustc even with a mechanism; that is a subject of ongoing discussion.)

[clubby789]

I think for now I'll open a PR folding this into clippy::non_minimal_cfg, and change this PR to only removing cfg(any()/all()) from this repo (reverting the Miri and Clippy changes), which will make it easier to potentially uplift the lint in future.
I'll also look at a MSRV mechanism for rustc lints in another PR

[clubby789]

MSRV'd version of the lint in #149870