Add future-incompat warning against keywords in cfgs and add raw-idents

[Urgau]

What does this PR try to resolve?

This PR tries to address this thread #14649 (comment) in #14649 regarding cfg(true)/cfg(false) (and keywords more generally) which are wrongly accepted¹ as ident.

To address this, this PR does two things:

1. it introduce a future-incompatibility warning against those (wrongly) accepted keywords as ident
2. it add parsing for raw-idents (r#true) add suggest-it in the warning

How should we test and review this PR?

This PR should be reviewed commit-by-commit.
Tests are included in preliminary commits.

Additional information

I added a new struct for representing Idents which is rawness aware.
Which implied updating cargo-platform to 0.2.0 due to the API changes.

r? @epage

Footnotes

1. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ccfb9c894dbf14e791c8ae7e4798efd0 ↩

[epage]

@rfcbot fcp merge

This PR adds a future-incompat warning for the use of true and false values in a cfg within Cargo. This is to make room supporting RFC3695 (see #14649) which we verbally confirmed approval for (see rust-lang/rfcs#3695 (comment))

The main focus of this FCP is insta-stabilizing support for raw identifiers (e.g. r#true) in cfgs in Cargo. The future-incompat warning (this PR) and support for true / false (#14649) is implemented in a way that mirrors rustc where true and false are considered keywords and to reference the identifers with those names you need to use raw identifiers.

[rfcbot]

Team member @epage has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @Muscraft
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[ehuss]

I'm not quite sure I understand the wording of the error message. Saying cfg(true) is deprecated and will become a hard error in a future doesn't seem correct, since when rust-lang/rust#131204 is stabilized, it will become a supported feature (and thus not deprecated, and will intentionally be supported), right?

Would it be possible to change the wording to be something more like:

warning: the meaning of cfg(true) may change in the future
Cargo used to erroneously allow cfg(true) and cfg(false), but both forms were interpreted as false unless manually overridden with --cfg. In the future these will be built-in defines that will have the corresponding true/false value. It is recommended to avoid using these values until they are properly supported. See rust-lang/rust#131204 for more information.

[Urgau]

[..] it will become a supported feature (and thus not deprecated, and will intentionally be supported), right?

Yes, cfg(true) and cfg(false) will have the right semantic after #14649 is stabilized.

Changed the wording as suggest.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[epage]

Thanks @Urgau !

[weihanglo]

---- test_proc_macro stdout ----
running `/home/runner/work/cargo/cargo/target/debug/cargo test --lib -Zbuild-std -Zpublic-dependency`
thread 'test_proc_macro' panicked at tests/build-std/main.rs:391:10:

---- expected: tests/build-std/main.rs:385:27
++++ actual:   stderr
        1 + [BLOCKING] waiting for file lock on package cache
        2 + [BLOCKING] waiting for file lock on package cache
   1    3 | [COMPILING] foo v0.0.0 ([ROOT]/foo)
   2    4 | [FINISHED] `test` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
   3    5 | [RUNNING] unittests src/lib.rs (target/debug/deps/foo-[HASH])

Hmm… build-std seems to clobber each others after #14850. Let me check how to fix it.

[weihanglo]

Got a PR up: #14861

[weihanglo]

Re-queuing as #14861 has been merged.