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

Unify AST Visitors with a macro like MIR Visitors #128974

Draft
wants to merge 82 commits into
base: master
Choose a base branch
from

Conversation

maxcabrajac
Copy link
Contributor

@maxcabrajac maxcabrajac commented Aug 11, 2024

This is a PR to work on #127615

@rustbot
Copy link
Collaborator

rustbot commented Aug 11, 2024

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @lcnr (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@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 Aug 11, 2024
@rust-log-analyzer

This comment has been minimized.

@cjgillot cjgillot self-assigned this Aug 11, 2024
@lcnr
Copy link
Contributor

lcnr commented Aug 12, 2024

r? compiler

@rustbot rustbot assigned davidtwco and unassigned cjgillot and lcnr Aug 12, 2024
@lcnr
Copy link
Contributor

lcnr commented Aug 12, 2024

r? @cjgillot woops

@rustbot rustbot assigned cjgillot and unassigned davidtwco Aug 12, 2024
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

Copy link
Contributor

@cjgillot cjgillot left a comment

Choose a reason for hiding this comment

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

Wow, that's some great work you did @maxcabrajac!
Please take this as an opportunity to simplify stuff. If some distinction has you make weird corner cases, don't hesitate to remove it. My comments are suggestions in this direction.

compiler/rustc_ast/src/visitors.rs Outdated Show resolved Hide resolved
compiler/rustc_ast/src/visitors.rs Outdated Show resolved Hide resolved
compiler/rustc_ast/src/visitors.rs Outdated Show resolved Hide resolved
Comment on lines 320 to 325
make_visit!{P!(Local), visit_local, walk_local}
make_visit!{P!(Pat), visit_pat, walk_pat}
make_visit!{P!(Expr), visit_expr, walk_expr}
make_visit!{P!(Ty), visit_ty, walk_ty}
make_visit!{P!(Block), visit_block, walk_block}
make_visit!{P!(FnDecl), visit_fn_decl, walk_fn_decl}
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we remove the P! from all these?

Copy link
Contributor Author

@maxcabrajac maxcabrajac Aug 27, 2024

Choose a reason for hiding this comment

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

I put these P! to maintain all function signatures the same, thus avoiding changes on implementers. I don't know why the original MutVisitor received &mut P<T> instead of &mut T for these types, but I just kept what was being done.

@maxcabrajac
Copy link
Contributor Author

I think it's better to do two passes. Do what can be done without changing the trait API, after that, change what is weird about their original implementation and change all implementers accordingly. What do you think about it?
There is a pretty big roadblock now... Everything around walk_item seems to be pretty different from Visitor to MutVisitor and I really don't know where to start =/. Do you have any advice on that?

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@maxcabrajac
Copy link
Contributor Author

Hey @cjgillot!
I just did a major history-rewrite of what I had done.
At first, I kept on the branch a bunch of changes that either didn't make to the final cut or were a bit unrelated and could be done in follow up PRs. (I have two tiny follow-up PRs in mind)
Now the commit history is much cleaner! I think that If anyone wants to check if nothing was missed (what is a immense, but doable task) going through the diffs should be ok.
Could you please have a look at it? =)

Hey @oli-obk!
Your input would also be highly appreciated!

@maxcabrajac
Copy link
Contributor Author

maxcabrajac commented Oct 23, 2024

Hey @cjgillot !
Could you comment "hi"/"ACK"/anything when you see this?
I think my messages might have gotten buried or something like that and you missed them. =(
Thanks =)

@petrochenkov
Copy link
Contributor

petrochenkov commented Oct 23, 2024

I was also going to look at this PR, but didn't because it's too large, and I couldn't allocate enough time.
If some refactorings can be reasonably split into separate PRs, then doing that should speed up the reviewing/landing process.

@petrochenkov petrochenkov self-assigned this Oct 23, 2024
@maxcabrajac
Copy link
Contributor Author

maxcabrajac commented Oct 23, 2024

Hi @petrochenkov!

Thanks for the reply =)
I'm in no rush, I would love for you to have a look at it. =)
Sadly, I don't know how I to reasonably split this into PRs that don't look out of place...
Assuming that leaving it looking like a WIP inbetween PRs is ok (which I think it isn't) this is the best I can do is:

  • Remove visit_expr_post (d6a89c1 this seems reasonable to be its own PR, but has be done before the f097c35)
  • Unify all of the visit/walks that are already mostly uniform (everything up to commit 089d0ee)
  • Unify the problematic ones, namely, *_item and *_fn (from fcb93eb to 0e75ea0)
  • Unify walk_expr as it depends on *_fn being uniform (f097c35)
  • Unify flatmaps (from a6d7ecc to 24465fd)

There were some changes I did on my first try/think can be done that I pulled out to do in follow up PR's:

  • Add flatmaps for some suitable nodes (eg. Attributes)
  • Use visit_coroutine_kind in rustc_lint/src/early.rs
  • Overload visit_* instead of flatmap_* in rustc_builtin_macros/src/cfg_eval.rs

What do you think about it?

@petrochenkov
Copy link
Contributor

Assuming that leaving it looking like a WIP inbetween PRs is ok

It's ok, anything is better than a PR with 3k+ diff.

I suggest first landing changes unifying interfaces between mutable and immutable visitors.
No macros, no mass moving code between files/modules, etc, 900 lines diff is a limit for a PR.

If something is changed in visiting interfaces of Idents, Symbols, Spans or NodeIds then it needs to be submitted separately for benchmarking.

Feel free to assign such PRs to me.

(Also, splitting "introduce X" and "use X to do something" into separate commits is not very useful, especially if X is not large.)

@petrochenkov
Copy link
Contributor

The macros here look pretty terrifying, TBH.
With the old code it's trivial to understand what happens, while the new code requires time and some macro expertise.
Perhaps using proc macros would be more readable in this case.
But we can decide on that after the first part is merged.

@petrochenkov petrochenkov 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 Oct 24, 2024
@maxcabrajac
Copy link
Contributor Author

Ok! I'll do that then!

@rustbot rustbot added the has-merge-commits PR has merge commits, merge with caution. label Oct 24, 2024
@rustbot
Copy link
Collaborator

rustbot commented Oct 24, 2024

There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

You can start a rebase with the following commands:

$ # rebase
$ git pull --rebase https://github.com/rust-lang/rust.git master
$ git push --force-with-lease

The following commits are merge commits:

@petrochenkov
Copy link
Contributor

petrochenkov commented Oct 24, 2024

@maxcabrajac
To clarify, could you keep the full set of changes in this PR, and make new PRs for the partial changes?

Upd: could you also refer to this PR from PR descriptions of the other PRs?

@maxcabrajac
Copy link
Contributor Author

@maxcabrajac To clarify, could you keep the full set of changes in this PR, and make new PRs for the partial changes?

That force push to this PR was just because I missclicked "Sync fork" on the wrong branch and wanted to revert it. I'm keeping this as reference for what to do in the other PRs.

Now I'm doing what can be done before introducing macros, ok?

Upd: could you also refer to this PR from PR descriptions of the other PRs?

Added "related to #this PR" to them.

One last thing:

The macros here look pretty terrifying, TBH.

Is make_visit the one that bothers? One my first try I didn't use this approach, but opted for it when there were 500 lines of just:

fn visit_t(&mut self, t: &$($lt)? $($mut)? T)) -> result!() {
    walk_t(self, t)
}

After already using make_visit for things, I needed to make it pass additional arguments around, which might not have come out great...
That being said, we can either remove or improve make_visit if it fits. =)

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Oct 24, 2024
…trochenkov

Remove visit_expr_post from ast Visitor

`visit_expr_post` is only present in the immutable version of ast Visitors and its default implementation is a noop.
Given that its only implementer is on `rustc_lint/src/early.rs` and its name follows the same naming convention as some other lints (`_post`), it seems that `visit_expr_post` being in `Visitor` was a little mistake.

r? `@petrochenkov`

related to rust-lang#128974
@petrochenkov
Copy link
Contributor

Now I'm doing what can be done before introducing macros, ok?

👍

Is make_visit the one that bothers?

I didn't look into much detail yet, just a general feeling (e.g. there are multiple layers of macros, a dozen of helper macros, etc).

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Oct 24, 2024
Rollup merge of rust-lang#132107 - maxcabrajac:remove_expr_post, r=petrochenkov

Remove visit_expr_post from ast Visitor

`visit_expr_post` is only present in the immutable version of ast Visitors and its default implementation is a noop.
Given that its only implementer is on `rustc_lint/src/early.rs` and its name follows the same naming convention as some other lints (`_post`), it seems that `visit_expr_post` being in `Visitor` was a little mistake.

r? `@petrochenkov`

related to rust-lang#128974
@bors
Copy link
Contributor

bors commented Oct 24, 2024

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

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Oct 25, 2024
Pass Ident by reference in ast Visitor

`MutVisitor`'s version of `visit_ident` passes around `&Ident`, but `Visitor` copies `Ident`. This PR changes that

r? `@petrochenkov`

related to rust-lang#128974
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Oct 25, 2024
Rollup merge of rust-lang#132106 - maxcabrajac:ident_ref, r=petrochenkov

Pass Ident by reference in ast Visitor

`MutVisitor`'s version of `visit_ident` passes around `&Ident`, but `Visitor` copies `Ident`. This PR changes that

r? `@petrochenkov`

related to rust-lang#128974
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has-merge-commits PR has merge commits, merge with caution. 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.

9 participants