Fix crate name validation #127581

fmease · 2024-07-10T16:49:05Z

Reject macro calls inside attribute #![crate_name] like in #![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 · 2024-07-10T16:49:13Z

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

compiler/rustc_interface/src/util.rs

fmease · 2024-07-18T22:09:38Z

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

wesleywiser

Is the last commit still WIP?

compiler/rustc_expand/src/module.rs

fmease · 2024-07-31T18:20:51Z

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.

bjorn3 · 2025-02-14T10:35:45Z

compiler/rustc_interface/src/passes.rs

+pub fn get_crate_name(sess: &Session, krate_attrs: &[ast::Attribute]) -> Symbol {
+    // We unconditionally validate all `#![crate_name]`s even if a crate name was
+    // set on the command line via `--crate-name` which we prioritize over the
+    // crate attributes. We perform the validation here instead of later to ensure


--crate-name isn't prioritized. Rather it and #![crate_name] must match.

bjorn3 · 2025-02-14T10:36:29Z

r? @bjorn3

Gets rid of two top-level UI tests which is always great. Furthermore, move `need-crate-arg-ignore-tidy$x.rs` from `command/` to `invalid-compile-flags/`. `command/` concerns `std::process::Command` tests, not CLI tests.

fmease · 2025-02-15T15:56:06Z

I take the approval as an "r=me with nit addressed".
@bors r=bjorn3

bors · 2025-02-15T15:56:08Z

📌 Commit 9b6fd35 has been approved by bjorn3

It is now in the queue for this repository.

…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#127581 (Fix crate name validation) - rust-lang#136490 (Do not allow attributes on struct field rest patterns) - rust-lang#136808 (Try to recover from path sep error in type parsing) - rust-lang#137055 (rustdoc: Properly restore search input placeholder) - rust-lang#137068 (fix(rustdoc): Fixed `Copy Item Path` in rust doc) - rust-lang#137070 (Do not generate invalid links in job summaries) - rust-lang#137074 (compiletest: add `{ignore,only}-rustc_abi-x86-sse2` directives) - rust-lang#137076 (triagebot.toml: ping me on changes to `tests/rustdoc-json`) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#127581 - fmease:fix-crate_name-validation, r=bjorn3 Fix crate name validation Reject macro calls inside attribute `#![crate_name]` like in `#![crate_name = concat!("na", "me")]`. Prior to rust-lang#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 rust-lang#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 rust-lang#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: rust-lang#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 rust-lang#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 rust-lang#122001. https://github.com/rust-lang/rust/labels/relnotes: Compatibility. Breaking change.

fmease added the relnotes Marks issues that should be documented in the release notes of the next release. label Jul 10, 2024

rustbot assigned wesleywiser Jul 10, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 10, 2024

fmease commented Jul 10, 2024

View reviewed changes

compiler/rustc_interface/src/util.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

This comment was marked as duplicate.

Sign in to view

fmease marked this pull request as draft July 10, 2024 17:26

fmease force-pushed the fix-crate_name-validation branch from 7b933ad to 3de58e6 Compare July 10, 2024 17:51

fmease marked this pull request as ready for review July 10, 2024 17:51

This comment has been minimized.

Sign in to view

fmease changed the title ~~Fix crate name validation~~ Fix crate name validation & cleanup Jul 10, 2024

fmease changed the title ~~Fix crate name validation & cleanup~~ Fix crate name validation & clean up Jul 10, 2024

fmease force-pushed the fix-crate_name-validation branch from 3de58e6 to e688f5e Compare July 10, 2024 20:37