Skip to content

fix(macros): allow custom attributes on exported macros#152190

Closed
nyurik wants to merge 1 commit intorust-lang:mainfrom
nyurik:bug-150518
Closed

fix(macros): allow custom attributes on exported macros#152190
nyurik wants to merge 1 commit intorust-lang:mainfrom
nyurik:bug-150518

Conversation

@nyurik
Copy link
Contributor

@nyurik nyurik commented Feb 5, 2026

fixes #98291

@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 Feb 5, 2026
@rustbot
Copy link
Collaborator

rustbot commented Feb 5, 2026

r? @jieyouxu

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

Why was this reviewer chosen?

The reviewer was selected based on:

  • People who recently interacted with files modified in this PR: compiler
  • compiler expanded to 20 candidates
  • Random selection from 12 candidates

@rust-log-analyzer

This comment has been minimized.

@jieyouxu
Copy link
Member

jieyouxu commented Feb 6, 2026

Maybe r? @petrochenkov

@petrochenkov
Copy link
Contributor

This is not a correct change.
The point of macro_expanded_macro_exports_accessed_by_absolute_paths is to prohibit uses of #[macro_export] declarations produced by any macros/attributes going through name resolution, including tool attributes like #[rust_analyzer::macro_style].
Because before doing name resolution we don't know whether #[rust_analyzer::macro_style] is a tool attribute or a macro.

It's possible that the error can be relaxed in some cases, but doing that is involved, see links from the tracking issue (#144408) for more details.

@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 9, 2026
@nyurik
Copy link
Contributor Author

nyurik commented Feb 9, 2026

@petrochenkov Thanks for speedy review! At the moment, it is impossible to add a Could you give some further guidance on how #[clippy::format_args] can be allowed in the user code - what compiler changes could lead to supporting it? I would love to solve #98291, so any general guidance would be helpful.

@petrochenkov
Copy link
Contributor

what compiler changes could lead to supporting it?

I don't know exactly, this needs some investigation by an expert (i.e. me :D).
Probably moving #[macro_export] declarations to a separate Scope, at least partially?
Probably some changes in resolve_ident_in_module_(non_)globs_unadjusted to process determinacy for #[macro_export] declarations more precisely?
Moving the macro_expanded_macro_exports_accessed_by_absolute_paths error to maybe_push_ambiguity.

@nyurik nyurik deleted the bug-150518 branch February 9, 2026 20:13
@nyurik nyurik restored the bug-150518 branch February 9, 2026 20:19
@nyurik
Copy link
Contributor Author

nyurik commented Feb 9, 2026

@petrochenkov thx, AI suggested this change 71dc761...nyurik:rust:bug-150518 (just in case it might help you), but I will wait for the expert investigation :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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.

Adding an attribute to a macro_exported macro and reexporting it incorrectly triggers the macro_expanded_macro_exports_accessed_by_absolute_paths error

5 participants