ast: Keep expansion status for out-of-line module items #82238
Conversation
|
r? @estebank (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
r? @Aaron1011 |
jyn514
added
A-parser
compiler/rustc_ast/src/mut_visit.rs
Outdated
| @@ -1014,19 +1010,18 @@ pub fn noop_visit_crate<T: MutVisitor>(krate: &mut Crate, vis: &mut T) { | |||
| id: DUMMY_NODE_ID, | |||
| vis: item_vis, | |||
| span, | |||
| kind: ItemKind::Mod(module), | |||
| kind: ItemKind::Mod(Mod { inner: span, unsafety: Unsafe::No, items, inline: true }), | |||
There was a problem hiding this comment.
Constructing this synthetic Mod seems kind of unfortunate, but it looks like it's necessary for the flat_map_item handling below.
There was a problem hiding this comment.
I don't like this either and left a FIXME above.
I'll try to investigate removing this some time later, together with similar code in fn expand_crate.
| fn visit_mod(&mut self, m: &'a Mod, _s: Span, _attrs: &[Attribute], n: NodeId) { | ||
| let def_id = self.lctx.lower_node_id(n).expect_owner(); | ||
|
|
||
| self.lctx.modules.insert( |
There was a problem hiding this comment.
Could this be moved to the ItemKind::Mod(..) => match arm below? That would allow you to avoid using lctx.modules.entry in some of the other code.
There was a problem hiding this comment.
I think entry is preferable, why pre-inserting empty values explicitly if entry can do everything for you automatically.
There was a problem hiding this comment.
I thought that the get_mut().unwrap() might have been a check to ensure that we had already processed the module in some way. If that's not the case, then I think your change is fine.
Crate root is sufficiently different from `mod` items, at least at syntactic level. Also remove customization point for "`mod` item or crate root" from AST visitors.
Also remove `ast::Mod` which is mostly redundant now
petrochenkov
force-pushed
the
nocratemod
branch
from
1e0132e to
4a88165
Compare
| self.end(); // end inner head-block | ||
| self.end(); // end outer head-block | ||
| match mod_kind { | ||
| ModKind::Loaded(items, ..) => { |
There was a problem hiding this comment.
It looks like this will always pretty-print the contents of outline modules - is that intentional?
There was a problem hiding this comment.
For --pretty=normal and --pretty=expanded this is a replacement of the removed self.is_expanded flag.
For synthesizing tokens for inner macro attributes on modules (which are broken until #81661 is fixed) I think it also makes sense to tokenize the whole module rather than just the mod foo; header.
|
r=me assuming that the pretty-printer change is intentional. |
|
@bors r+ |
|
📌 Commit 4a88165 has been approved by |
bors
added
S-waiting-on-bors
Rollup of 10 pull requests Successful merges: - rust-lang#79747 (Add explanations and suggestions to `irrefutable_let_patterns` lint) - rust-lang#81496 (name async generators something more human friendly in type error diagnostic) - rust-lang#81873 (Add Mutex::unlock) - rust-lang#82093 (Add tests for Atomic*::fetch_{min,max}) - rust-lang#82238 (ast: Keep expansion status for out-of-line module items) - rust-lang#82245 (Do not ICE when evaluating locals' types of invalid `yield`) - rust-lang#82259 (Fix popping singleton paths in when generating E0433) - rust-lang#82261 (rustdoc: Support argument files) - rust-lang#82274 (libtest: Fix unwrap panic on duplicate TestDesc) - rust-lang#82275 (Update cargo) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
ast: Keep expansion status for out-of-line module items I.e. whether a module `mod foo;` is already loaded from a file or not. This is a pre-requisite to correctly treating inner attributes on such modules (rust-lang#81661). With this change AST structures for `mod` items diverge even more for AST structure for the crate root, which previously used `ast::Mod`. Therefore this PR removes `ast::Mod` from `ast::Crate` in the first commit, these two things are sufficiently different from each other, at least at syntactic level. Customization points for visiting a "`mod` item or crate root" were also removed from AST visitors (`fn visit_mod`). `ast::Mod` itself was refactored away in the second commit in favor of `ItemKind::Mod(Unsafe, ModKind)`.
expand: Turn `ast::Crate` into a first class expansion target And stop creating a fake `mod` item for the crate root when expanding a crate, thus addressing FIXMEs left in rust-lang#82238, and making a step towards a proper support for crate-level macro attributes (cc rust-lang#54726). I haven't added token collection support for the whole crate in this PR, maybe later. r? `@Aaron1011`
I.e. whether a module
mod foo;is already loaded from a file or not.This is a pre-requisite to correctly treating inner attributes on such modules (#81661).
With this change AST structures for
moditems diverge even more for AST structure for the crate root, which previously usedast::Mod.Therefore this PR removes
ast::Modfromast::Cratein the first commit, these two things are sufficiently different from each other, at least at syntactic level.Customization points for visiting a "
moditem or crate root" were also removed from AST visitors (fn visit_mod).ast::Moditself was refactored away in the second commit in favor ofItemKind::Mod(Unsafe, ModKind).