Skip to content
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

Fix anon const def-creation when macros are involved take 2 #130337

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

Conversation

BoxyUwU
Copy link
Member

@BoxyUwU BoxyUwU commented Sep 14, 2024

Fixes #130321

There were two cases that #129137 did not handle correctly:

  • Given a const argument Foo<{ bar!() }> in which bar!() expands to N, we would visit the anon const and then visit the { bar() } expression instead of visiting the macro call. This meant that we would build a def for the anon const as { bar!() } is not a trivial const argument as bar!() is not a path.
  • Given a const argument Foo<{ bar!() }> is which bar!() expands to { qux!() } in which qux!() expands to N, it should not be considered a trivial const argument as {{ N }} has two pairs of braces. If we only looked at qux's expansion it would look like a trivial const argument even though it is not. We have to track whether we have "unwrapped" a brace already when recursing into the expansions of bar/qux/any macro

r? @camelid

@rustbot 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 Sep 14, 2024
self.is_const_arg_trivial_macro_expansion(&*constant.value, Some(&constant))
{
self.pending_anon_const_info = Some(pending_anon);
return self.visit_macro_invoc(macro_invoc);
Copy link
Member Author

Choose a reason for hiding this comment

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

This change to call visit_macro_invoc instead of walk_anon_const is what fixes #130321. Everything else in this PR is changes made to track if we've already unwrapped a brace or not (and related code deduplication since it would be pretty messy otherwise)

@@ -1199,14 +1199,15 @@ impl Expr {
}
}

pub fn maybe_unwrap_block(&self) -> &Expr {
/// Returns an expression with (when possible) *one* outter brace removed
pub fn maybe_unwrap_block(&self) -> (bool, &Expr) {
Copy link
Member

Choose a reason for hiding this comment

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

Wondering if it would be clearer to return Option<&Expr> (also matching the function's name)? Then it could be used as expr.maybe_unwrap_block().unwrap_or(expr) e.g. Maybe that'd be worse, but it just came to mind.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah I think this is probably just worse for every caller unfortunately because this is not the nicest name/signature combo 😅

compiler/rustc_resolve/src/def_collector.rs Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ICE: adding a def'n for node-id NodeId(17) and def kind AnonConst but a previous def'n exists
3 participants