Fix crate name validation

[fmease]

Reject macro calls inside attribute #![crate_name] like #![crate_name = concat!("na", "me")].

Prior to #117584, the result of the expansion (here: "name") would actually be properly picked up by the compiler and used as the crate name. However since #117584 / on master, we extract the "value" (i.e., the literal string literal) of the #![crate_name] much earlier in the pipeline way before macro expansion and skip/ignore any #![crate_name]s "assigned to" a macro call. See also #122001.

T-lang has ruled to reject #![crate_name = MACRO!(...)] outright very similar to other built-in attributes whose value we need early like #![crate_type]. See accepted FCP: #122001 (comment).

Note that the check as implemented in this PR is even more "aggressive" compared to the one of #![crate_type] by running as early as possible in order to reject #![crate_name = MACRO!(...)] even in "non-normal" executions of rustc, namely on print requests (e.g., --print=crate-name and --print=file-names). If I were to move the validation step a bit further back close to the #![crate_type] one, --print=crate-name (etc.) would not exit fatally with an error in this kind of situation but happily report an incorrect crate name (i.e., the "crate name" as if #![crate_name] didn't exist / deduced from other sources like --crate-name or the file name) which would match the behavior on master. Again, see also #122001.

I'm mentioning this explicitly because I'm not sure if it was that clear in the FCP'ed issue. I argue that my current approach is the most reasonable one. I know (from reading the code and from past experiments) that various print requests are still quite broken (mostly lack of validation).

To the best of my knowledge, there's no print request whose output references/contains a crate type, so there's no "inherent need" to move #![crate_type]'s validation to happen earlier.

---

Fixes #122001.

relnotes Marks issues that should be documented in the release notes of the next release. : Compatibility. Breaking change.

[rustbot]

r? @wesleywiser

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

[fmease]

I've finally added a proper PR description. Sorry about the delay ^^'.

[wesleywiser]

Is the last commit still WIP?

[fmease]

Is the last commit still WIP?

I've now dropped the WIP commit as I still need to investigate the implications of its changes. I'll submit it as a follow-up PR if everything works out.

I've adjusted the wording in the comment to no longer use the word 'currently'.

Ready for re-review. Nothing WIP left.

[fmease]

I've dropped the tests/ui/{invalid-compile-flags → cli}/ change. See discussion in #133277.