Introduce proc_macro_back_compat lint, and emit for time-macros-impl

[Aaron1011]

Now that future-incompat-report support has landed in nightly Cargo, we
can start to make progress towards removing the various proc-macro
back-compat hacks that have accumulated in the compiler.

This PR introduces a new lint proc_macro_back_compat, which results in
a future-incompat-report entry being generated. All proc-macro
back-compat warnings will be grouped under this lint. Note that this
lint will never actually become a hard error - instead, we will remove
the special cases for various macros, which will cause older versions of
those crates to emit some other error.

I've added code to fire this lint for the time-macros-impl case. This
is the easiest case out of all of our current back-compat hacks - the
crate was renamed to time-macros, so seeing a filename with
time-macros-impl guarantees that an older version of the parent time
crate is in use.

When Cargo's future-incompat-report feature gets stabilized, affected
users will start to see future-incompat warnings when they build their
crates.

[rust-highfive]

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

[Aaron1011]

r? @petrochenkov

[petrochenkov]

The lint documentation needs to be adjusted as described in the doc comment to macro_rules! declare_lint to pass the lint tidy checking.
Otherwise r=me.

[Aaron1011]

@bors r=petrochenkov

[bors]

📌 Commit f190bc4 has been approved by petrochenkov

[jhpratt]

Hey there! As the maintainer of the time-macros-impl crate, what behavior should change (if any)?

And with regard to the crate renaming, this hasn't yet happened on crates.io, but the code on the main branch is completely different (rewritten to avoid using syn/quote).

[Aaron1011]

Hey there! As the maintainer of the time-macros-impl crate, what behavior should change (if any)?

There isn't actually anything wrong with time-macros-impl - this is a workaround for #72545.

In order to land a TokenStream bugfix without major ecosystem breakage, we implemented a hack to pass the 'old' (without None-delimited groups) TokenStream to certain proc-macros. The actual bug was in proc-macro-hack, but to limit the scope of the hack, we only applied to the crates causing significant breakage.

To answer your question: this shouldn't affect the behavior of any versions of time. Anyone using older versions of time-macros-impl will eventually need to bump their proc-macro-hack version, or update to the latest version of time (which doesn't use proc-macro-hack). Anyone who doesn't do one of those two things will eventually get a compilation error - there will be no change for any crates that compile without a warning.

[jhpratt]

Ah, I remember when that happened in proc-macro-hack. Thanks for the info.