)]}'
{
  "commit": "a9eeba2ab9526efca8148dccd095286d3c393dd4",
  "tree": "cce0e2985da6ed7a9962b9ee9110f59aae65837b",
  "parents": [
    "09300b80570836b2736477e43e3897cf1060a27d",
    "5e016b66c3b14d2934eb64d344e91c2246578ed5"
  ],
  "author": {
    "name": "Jonathan Brouwer",
    "email": "jonathantbrouwer@gmail.com",
    "time": "Sun Jul 05 14:12:05 2026 +0200"
  },
  "committer": {
    "name": "GitHub",
    "email": "noreply@github.com",
    "time": "Sun Jul 05 14:12:05 2026 +0200"
  },
  "message": "Rollup merge of #157857 - TimNN:macro-mod, r\u003dpetrochenkov\n\nStabilize `#[my_macro] mod foo;` (part of `proc_macro_hygiene`)\n\n# Stabilization report\n\n## Summary\n\nAllow `mod foo;` (an \"outlined\" module) in the input of attribute and derive (proc) macros.\n\nTracking:\n\n- https://github.com/rust-lang/rust/issues/54727\n    - The `proc_macro_hygiene` feature covers multiple related features. This PR proposes only a partial stabilization\n\nReference PRs:\n\n- https://github.com/rust-lang/reference/pull/2284\n\n### What is stabilized\n\n\u003e Describe each behavior being stabilized and give a short example of code that will now be accepted.\n\nCurrently, `mod foo;` (an outlined / non-inline) module is explicitly rejected in the input of derive and attribute (proc) macros.\n\nThis PR removes the check, allowing `mod foo;`.\n\nThe module is provided to the macro as it is written in the source code, that is in its \"not-yet-loaded\" form without a body.\n\n```rust\n// The following was previously rejected and will now compile.\n\n#[my_proc_macro]\nmod foo;\n\n#[my_proc_macro]\nfn bar() {\n    #[path \u003d \"foo.rs\"]\n    mod foo;\n}\n\n#[derive(MyTrait)]\nstruct Foo([u8; {\n    #[path \u003d \"foo.rs\"]\n    mod foo;\n    0\n}]);\n```\n\n### What isn\u0027t stabilized\n\n\u003e Describe any parts of the feature not being stabilized. Talk about what we might want to do later and what doors are being left open for that. If what we\u0027re not stabilizing might lead to surprises for users, talk about that in particular.\n\nThe remaining parts of `proc_macro_hygiene` are not stabilized (specifically, attribute macros in places where they aren\u0027t currently allowed).\n\n## Design\n\n### Reference\n\n\u003e What updates are needed to the Reference? Link to each PR. If the Reference is missing content needed for describing this feature, discuss that.\n\nhttps://github.com/rust-lang/reference/pull/2284\n\n### RFC history\n\n\u003e What RFCs have been accepted for this feature?\n\nThis feature has not been explicitly specified by any RFC.\n\n- Ahead of the `proc_macro` stabilization, `#[my_macro] mod foo;` specifically was feature gated.\n- As a side effect of https://github.com/rust-lang/rust/pull/52319, the (unstable) behavior changed:\n    - Before that PR, `mod foo;` was actually provided to macros as the loaded `mod foo { ... }`\n    - After that PR, `mod foo;` was provided to macros as-is.\n- In 2019 (after the `proc_macro` stabilization, https://github.com/rust-lang/rust/pull/66078 made `mod foo` _**anywhere**_ in the input to derive or attribute proc macros unstable.\n    - Before that PR, only proc macros directly applied to `mod foo;` were unstable.\n\n### Answers to unresolved questions\n\n\u003e What questions were left unresolved by the RFC? How have they been answered? Link to any relevant lang decisions.\n\nN/A\n\n### Post-RFC changes\n\n\u003e What other user-visible changes have occurred since the RFC was accepted? Describe both changes that the lang team accepted (and link to those decisions) as well as changes that are being presented to the team for the first time in this stabilization report.\n\nSee the RFC history above.\n\n### Key points\n\n\u003e What decisions have been most difficult and what behaviors to be stabilized have proved most contentious? Summarize the major arguments on all sides and link to earlier documents and discussions.\n\nThe main design decision is whether outlined modules should be passed to proc macros with or without their body.\n\nArguments in favor of \"without their body\":\n\n- (To the best of my knowledge) the current compiler architecture makes \"without their body\" the natural choice.\n    - To [quote](https://github.com/rust-lang/rust/issues/54727#issuecomment-4643290397) @petrochenkov, \"it\u0027s clear that the current behavior of `#[my_macro] mod foo;` (the \"not-yet-loaded\" version of the module is passed to the macro) is natural to the current setup, stable and is not going to change\".\n- At least I would be somewhat surprised to see a macro (which is operating on the AST) able to see or affect code outside the current file. I would assume by default that they get as input exactly what I have written.\n- Function-like procedural macros operate on arbitrary token trees. `mod foo;` in their input is not even recognized by the compiler and thus not expanded. Attribute and derive proc macros also receiving the unexpanded `mod foo;` in their input makes the two consistent.\n- Other syntactic constructs, e.g. other macros like `inlcude!(\"foo.rs\")`, are also not expanded before being passed to proc macros. Providing modules without their body would be consistent with that.\n- Providing `mod foo;` to proc macros with its body would (as far as I know) be the only case where a proc macro would not get exactly what is written in the source code as its input.\n\nArguments in favor of \"with their body\":\n\n- `#[my_macro] mod foo;` and `#[my_macro] mod foo {}` would have different behavior, which means that in the presence of proc macros, migrating an inline module to an outlined one would no longer be a purely syntactic change, but could affect the behavior of the proc macro.\n- `#[my_macro] mod foo;` and `#![my_macro]` in `foo.rs` ([currently unstable](https://github.com/rust-lang/rust/issues/54726)) would have different behavior.\n    - Other attributes already have different behaviors depending on whether they are applied as inner vs outer attributes. For example `#[cfg(false)]` on a module as an outer attribute means the corresponding file can be missig or have syntax errors, while using it as an inner attribute requires the file to be syntactically valid.\n- Some macros may need access to (or change) the module body to function properly.\n\n### Nightly extensions\n\n\u003e Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?\n\nNo.\n\n### Doors closed\n\n\u003e What doors does this stabilization close for later changes to the language? E.g., does this stabilization make any other RFCs, lang experiments, or known in-flight proposals more difficult or impossible to do later?\n\nNone.\n\nIf, in the future, there is a desire to make the module body of outlined modules available to proc macros, there are multiple ways to add that in a backward-compatible way (e.g. an explicit opt-in during the proc macro registration, or an API in the `proc_macro` crate).\n\n## Feedback\n\n### Call for testing\n\n\u003e Has a \"call for testing\" been done? If so, what feedback was received?\n\nNo.\n\n### Nightly use\n\n\u003e Do any known nightly users use this feature? Counting instances of `#![feature(FEATURE_NAME)]` on GitHub with grep might be informative.\n\nSearching Github [produces](https://github.com/search?q\u003d%22feature%28proc_macro_hygiene%29%22+language%3ARust+\u0026type\u003dcode) 4.4k files. Reviewing the first page of results shows many repositories that haven\u0027t been updated in multiple years, so it is unclear which part of the `proc_macro_hygiene` feature they actually use (other parts of the feature were previously stabilized).\n\n## Implementation\n\n### Major parts\n\n\u003e Summarize the major parts of the implementation and provide links into the code and to relevant PRs.\n\nThe restriction is currently implemented as an explicit visitor of the proc macro input, rejecting outlined modules. The visitor is removed in this PR.\n\n### Coverage\n\n\u003e Summarize the test coverage of this feature.\n\nSee the test changes attached to this PR. The added tests explicitly verify that proc macros receive `mod foo;` as an input without its body, to ensure that the behavior doesn\u0027t unintentionally change in the future.\n\n### Outstanding bugs\n\n\u003e What outstanding bugs involve this feature? List them. Should any block the stabilization? Discuss why or why not.\n\nNone.\n\n### Outstanding FIXMEs\n\n\u003e What FIXMEs are still in the code for that feature and why is it OK to leave them there?\n\nNone.\n\n### Tool changes\n\n\u003e What changes must be made to our other tools to support this feature. Has this work been done? Link to any relevant PRs and issues.\n\nGenerally none. The feature is a minor addition to the inputs that (proc) macros accept, and should not require special handling in any of the tools.\n\nrust-analyzer has some existing limitations around handling modules transformed by proc macros (e.g. (on stable) auto-complete does not work if a proc macro transforms `mod foo {}` to `mod foo;`). It works fine for simple case where the the proc macro leaves the `mod foo;` mostly unmodified.\n\n### Breaking changes\n\n\u003e If this stabilization represents a known breaking change, link to the crater report, the analysis of the crater report, and to all PRs we\u0027ve made to ecosystem projects affected by this breakage. Discuss any limitations of what we\u0027re able to know about or to fix.\n\nN/A: The feature is not expected to cause any breakage.\n\n## Type system, opsem\n\nN/A: This feature only affects the AST, not type checking.\n\n## Common interactions\n\n### Temporaries\n\n\u003e Does this feature introduce new expressions that can produce temporaries? What are the scopes of those temporaries?\n\nNo.\n\n### Drop order\n\n\u003e Does this feature raise questions about the order in which we should drop values? Talk about the decisions made here and how they\u0027re consistent with our earlier decisions.\n\nNo.\n\n### Pre-expansion / post-expansion\n\n\u003e Does this feature raise questions about what should be accepted pre-expansion (e.g. in code covered by `#[cfg(false)]`) versus what should be accepted post-expansion? What decisions were made about this?\n\nNo. (At least nothing that doesn\u0027t equally apply to existing stable proc macros).\n\n### Edition hygiene\n\n\u003e If this feature is gated on an edition, how do we decide, in the context of the edition hygiene of tokens, whether to accept or reject code. E.g., what token do we use to decide?\n\nN/A: Not gated on an edition.\n\n### SemVer implications\n\n\u003e Does this feature create any new ways in which library authors must take care to prevent breaking downstreams when making minor-version releases? Describe these. Are these new hazards \"major\" or \"minor\" according to [RFC 1105](https://rust-lang.github.io/rfcs/1105-api-evolution.html)?\n\nNo.\n\n### Exposing other features\n\n\u003e Are there any other unstable features whose behavior may be exposed by this feature in any way? What features present the highest risk of that?\n\nNo.\n\n## History\n\n\u003e List issues and PRs that are important for understanding how we got here.\n\nSee the RFC History section above.\n\n## Acknowledgments\n\n\u003e Summarize contributors to the feature by name for recognition and so that those people are notified about the stabilization. Does anyone who worked on this _not_ think it should be stabilized right now? We\u0027d like to hear about that if so.\n\n- @alexcrichton for the work towards the initial proc-macro expansion.\n- @petrochenkov for significant work on hygiene and expansion since then.\n\n## Open items\n\n\u003e List any known items that have not yet been completed and that should be before this is stabilized.\n\nNone.\n\n---\n\nr? @petrochenkov for an initial review (feel free to edit the stabilization report if you like)\n",
  "tree_diff": []
}