Skip to content

Port #[crate_name] to the new attribute parsing infrastructure #137729

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jdonszelmann
Copy link
Contributor

@jdonszelmann jdonszelmann commented Feb 27, 2025

r? @fmease

Closes #137687

@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) 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 Feb 27, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@jdonszelmann jdonszelmann force-pushed the fix-137687 branch 2 times, most recently from 4e90cee to 21838d5 Compare February 27, 2025 16:51
@jdonszelmann
Copy link
Contributor Author

@fmease and I decided to delay this PR for a bit until more diagnostic infra for attrs lands (hopefully next week) to make the duplicate error a warning to be consistent with current master.

@fmease fmease added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 6, 2025
@fmease
Copy link
Member

fmease commented Mar 6, 2025

r=fmease,bjorn3 once that PR lands and you can downgrade the error to a lint warning again.

@bors delegate+

@bors
Copy link
Collaborator

bors commented Mar 6, 2025

✌️ @jdonszelmann, you can now approve this pull request!

If @fmease told you to "r=me" after making some further change, please make that change, then do @bors r=@fmease

@bors

This comment was marked as resolved.

@wesleywiser
Copy link
Member

Hi @jdonszelmann and @fmease, #137687 has reached beta so it would be great if we could resolve that via a beta-backport of this PR. Do you think it's possible to resolve the review feedback and merge this PR in the next week or so?

I can probably pitch in to help if necessary 🙂

@jdonszelmann
Copy link
Contributor Author

Hi there. We wanted to delay this until attribute diagnostics. Something that should not be a lot of work but I have not worked as much on recently as I maybe should. I can't to this tomorrow, but likely next week. The pr has been reviewed but there was a bit of an issue around incremental, which I now know how to solve but just haven't yet. Is that a reasonable timeframe? I am pretty busy with organising rust week atm, but knowing the solution I guess the only important thing is that it gets quick reviews? Let me know how that sounds

@wesleywiser
Copy link
Member

Just to clarify, will this PR then depend on the attribute diagnostics work? (Is that #138164?)

Generally, for backports, we try to keep the backport as small as possible so if this PR can be made to work independently of that PR (possibly even with a degraded diagnostics experience), that would be highly preferred.

@jdonszelmann
Copy link
Contributor Author

No. We decided to delay this because it's relatively low prio and any nice and permanent solution for this depends on that. I'll make a temp fix that at least doesn't ice separately then, that sounds better for now. I don't mind doing it, I know the problem now and then I also know how to fix it permanently later. You'll hear from me

@theemathas
Copy link
Contributor

theemathas commented May 1, 2025

Note that #137687 actually has two separate problems/subissues:

  1. A problem (lower priority) involving the #[crate_name] attribute.
  2. A problem (higher priority, found in a crater run) involving user-defined macro_rules and derive macros.

This PR only appears to address the first problem. The second problem would probably need to have a separate fix.

@jdonszelmann
Copy link
Contributor Author

jdonszelmann commented May 2, 2025

ok this is weird, I've copied just the tests over to master to fix it in a temporary way, but can no longer reporoduce the issue. Something else must have solved it in the meantime. Let me see what.

@jieyouxu
Copy link
Member

jieyouxu commented May 3, 2025

(I know I've said this in the other PR too, but just in case)

Just a heads up: I split #137687 into two issues:

@jdonszelmann
Copy link
Contributor Author

@rustbot review

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Aug 12, 2025
@bors

This comment was marked as resolved.

@jdonszelmann jdonszelmann added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 14, 2025
@rustbot

This comment was marked as resolved.

@rustbot

This comment has been minimized.

@jdonszelmann
Copy link
Contributor Author

@rustbot review

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 19, 2025
@bors
Copy link
Collaborator

bors commented Aug 19, 2025

☔ The latest upstream changes (presumably #145600) made this pull request unmergeable. Please resolve the merge conflicts.

@rustbot

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@bors

This comment was marked as resolved.

@rustbot
Copy link
Collaborator

rustbot commented Aug 21, 2025

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

@rustbot
Copy link
Collaborator

rustbot commented Aug 21, 2025

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Copy link
Member

@fmease fmease left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some small comments. r=me with nits addressed in one way or another

View changes since this review

@@ -9,7 +9,7 @@ rustc_abi = { path = "../rustc_abi" }
rustc_ast = { path = "../rustc_ast" }
rustc_data_structures = { path = "../rustc_data_structures" }
rustc_error_messages = { path = "../rustc_error_messages" }
rustc_hir_id = { path = "../rustc_hir_id" }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Partially undoes #145390 but I guess that's unavoidable (we'd need to move DefPathHash and AttributeLintKind to rustc_hir_id to be able to revert that which wouldn't make sense). #145390 was simply "overfitting" you could say.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sigh, I actually considered making a similar change in the past but found it too destructive of a thing to do and found other solutions. Was very surprised when I saw someone else ended up doing this anyway 🙃

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll move that some day in another PR

Comment on lines +27 to +30
let Some(name) = n.value_as_str() else {
cx.expected_string_literal(n.value_span, Some(n.value_as_lit()));
return None;
};
Copy link
Member

@fmease fmease Aug 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this regress #[crate_name = concat!("x")] fn f() {}? I guess it won't because concat! is already expanded by then?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, AttributeLintDecoratorOrEmitter, decorate_or_emit, etc. would be more accurate.

Or going vague, AttributeLintHandler, fn handle, DeferredAttributeLintHandler, type Handler: …;.

But if you feel it's too churny to go rename them again, it's okay to leave it.

@@ -1244,8 +1246,7 @@ pub fn get_crate_name(sess: &Session, krate_attrs: &[ast::Attribute]) -> Symbol
// in all code paths that require the crate name very early on, namely before
// macro expansion.

let attr_crate_name =
validate_and_find_value_str_builtin_attr(sym::crate_name, sess, krate_attrs);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(once we port #[recursion_limit], we can get rid of validate_and_find_value_str_builtin_attr)

}
}

struct DiagEmitter<'a, 'b>(&'a mut Diag<'b, ()>);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
struct DiagEmitter<'a, 'b>(&'a mut Diag<'b, ()>);
struct DiagDecorator<'a, 'b>(&'a mut Diag<'b, ()>);

@@ -1417,15 +1418,24 @@ pub struct TyCtxt<'tcx> {
gcx: &'tcx GlobalCtxt<'tcx>,
}

impl<'tcx> LintEmitter for TyCtxt<'tcx> {
fn emit_node_span_lint(
pub struct Decorator<'tcx>(TyCtxt<'tcx>, &'static Lint, HirId, MultiSpan);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
pub struct Decorator<'tcx>(TyCtxt<'tcx>, &'static Lint, HirId, MultiSpan);
pub struct Emitter<'tcx>(TyCtxt<'tcx>, &'static Lint, HirId, MultiSpan);

match style {
Some(ast::AttrStyle::Outer) => self.tcx.emit_node_span_lint(
match attr {
// FIXME(jdonszelmann) after https://github.com/rust-lang/rust/pull/145085 merges, move to attribute parsing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(#145085 has been merged)

|
LL | #[crate_name = "0900"]
| ^^^^^^^^^^^^^^^^^^^^^^
| ^^^^^^
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, the highlight should span the entire attribute; the problem isn't with the string literal (contrary to diagnostics like crate name must not be empty or `--crate-name` and `#[crate_name]` are required to match)

@@ -1244,8 +1246,7 @@ pub fn get_crate_name(sess: &Session, krate_attrs: &[ast::Attribute]) -> Symbol
// in all code paths that require the crate name very early on, namely before
// macro expansion.

let attr_crate_name =
validate_and_find_value_str_builtin_attr(sym::crate_name, sess, krate_attrs);
let attr_crate_name = parse_crate_name(sess, krate_attrs, ShouldEmit::ErrorsAndLints);
Copy link
Member

@fmease fmease Aug 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please make this raise a FatalError on parse error to address https://github.com/rust-lang/rust/pull/137729/files#r2267446182 or add a FIXME(fmease): Exit fatally on parse error. so I can do so as a follow-up?

@fmease fmease changed the title add test to reproduce #137687 and fix it by converting #[crate_name] to a new-style attribute parser Convert #[crate_name] to a new-style attribute parser Aug 21, 2025
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(random file)

Did this PR actually add a regression test for #137687? Did I miss it

@fmease fmease added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 21, 2025
@fmease fmease changed the title Convert #[crate_name] to a new-style attribute parser Port #[crate_name] to the new attribute parsing infrastructure Aug 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ICE: expr in place where literal is expected (builtin attr parsing)
9 participants