Add fuzzing and loom to well-known cfgs

[saethlin]

Just like miri, the cfgs fuzzing and loom are used for ecosystem-wide coordination. These are by definition well-known, so they should be included in the list.

[rustbot]

r? @Nadrieril

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

[rustbot]

Some changes occurred in cfg and check-cfg configuration

cc @Urgau

Some changes occurred in src/doc/rustc/src/check-cfg.md

cc @Urgau

Some changes occurred in tests/ui/check-cfg

cc @Urgau

[Nadrieril]

Implementation looks good. I don't know the policy for such changes though. @Urgau you seem to know about this :D wdyt?

[Urgau]

I have mixed feelings about adding those, not necessarily the same for both.

First this would diverge from the T-compiler FCP of the feature where the rule that was proposed was:

1. User facing (nightly or not) (rational: internal cfgs are by their name not to be shown)
2. Set by a Rust Toolchain tool (rational: rustc is not the only tool that sets cfgs, rustdoc sets doc and doctest, cargo-miri sets miri, docs.rs sets docsrs, ...)
3. Must be an immutable set of names and values (rational: if it's not immutable, rustc cannot possibly know the what to add; this excludes Cargo feature cfg)

As far as I know neither of them are set by any Rust Toolchain tool, failing the second point.

Secondly those two cfgs are very specific are IMO not very well known by the broad community and including them by-default for everyone is a really high bar that I don't think neither of them quite reach.

Thirdly they seems both related to crates.io (maybe fuzzing a bit less, but loom definitely) and including them in rustc seems very weird for projects that don't use crates.io or Cargo at all, like the Rust for Linux project.

Fourthly including loom would give some kind of "recommendation" (even if not intended) and would make the project liable for another project that we don't control.

However it seems that there is some desire in having them as well known cfgs, so I could be sold on having them as compatibility cfg (so no other ecosystem cfgs in the future).

One thing that would help with my first and second point, would be to make them Cargo well known cfgs (instead of rustc well known), like docsrs is.

@rustbot label -S-waiting-on-review +S-waiting-on-author +S-blocked
cc @epage

---

As for the implementation in this PR it's missing two anti-regressions entries in well-known-values.rs.

[epage]

Based on the conversation in #124800, I think having a PR up is premature.

[saethlin]

As far as I know neither of them are set by any Rust Toolchain tool, failing the second point.

The point being raised in issues is that adding a build script to correct the false positives is an undue burden on the ecosystem, because every maintainer separately has to teach Cargo/rustc about all the well-known ecosystem cfgs that they use. It is entirely unclear to me if this was FCP'd with that concern in mind. I certainly can't find any evidence that it was discussed, so it seems rather dubious to point at the FCP here.

I'm happy to bring this up in a compiler team meeting, unless someone can point me to where the compiler team already discussed this concern.

And I see @workingjubilee has voiced the same feedback as I have, independently #124800 (comment)

[epage]

imo this is a discussion better had on an Issue, rather than a PR

[saethlin]

One thing that would help with my first and second point, would be to make them Cargo well known cfgs

Closing because of this. I agree. I might do a similar PR to Cargo later.