`ast::mut_visit::MutVisitor` and `ast::visit::Visitor` do not have corresponding methods for all their methods

[oli-obk]

In contrast to the MIR mut and immut visitors

rust/compiler/rustc_middle/src/mir/visit.rs

Lines 1235 to 1236 in c92a8e4

	make_mir_visitor!(Visitor,);
	make_mir_visitor!(MutVisitor, mut);

which are generated from a single macro, and are thus exactly the same except for mutation, the ast visitors are each handwritten. Their method naming scheme doesn't even match up, so changing from a Visitor to a MutVisitor requires extensive changes.

Work items

• Adjust names so everything has the visit_* vs walk_* naming scheme
• Give every MutVisitor::visit_* method a corresponding flat_map_* method. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate.
  • we can make it so implementors can override either visit_foo or flat_map_foo without there being problems. The walk_bar functions must invoke flat_map_foo, so that they can pick up on more/fewer items being produced. So walk_flat_map_foo (which only ever maps to a single output element) needs to invoke visit_foo, not walk_foo. Otherwise overriding visit_foo will do nothing.
  • This should be using macros similar to what [WIP] Try optimizing noop AST mut visiting #127371 did, so you don't repeat yourself
• (Optional): move all the walk_ functions to defaulted methods on the trait (not sure this should be done, discuss on zulip first!) discussed, should not be done
• Give every MutVisitor::visit_* method a corresponding Visitor method and vice versa E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
• Create a macro that generates both visitors, including the walk_ functions in one go, just like with the MIR visitors E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.

Previous work

• Make ast MutVisitor have the same method name and style as Visitor #127524

[GrigorenkoPV]

Give every MutVisitor::visit_* method a corresponding Visitor method and vice versa

• Missing in Visitor::visit_*
  • angle_bracketed_parameter_data
  • coroutine_kind
  • fn_decl
  • foreign_mod
  • id
  • macro_def
  • meta_item
  • meta_list_item
  • mt
  • parenthesized_parameter_data
  • qself
  • span
  • where_clause
• Missing in MutVisitor::visit_*
  • arm
  • assoc_item
  • enum_def
  • expr_field
  • expr_post
  • field_def
  • fn_ret_ty
  • foreign_item
  • generic_param
  • item
  • mac_def
  • param
  • pat_field
  • stmt
  • variant
  • variant_discr

All of these should be added, correct?

[oli-obk]

For the ones that only exist in Visitor but not in MutVisitor, it may be useful to see if anyone actually overrides these and potentially entirely remove them.

For the ones that only exist in MutVisitor but not Visitor, there are some that don't really make sense for Visitor, like the one for ids or the one for spans. There won't be any immutable visitors that just want to see all spans I think. So it seems ok to have such differences for leaf functions (where the Walker is a noop)

[oli-obk]

Also sometimes MutVisitor has things like ItemKind visiting, but not Item...

Looks like my idea was a bit naive. We basically need to analyze every missing method and see if there isn't one almost like it and if it can reasonably be refactored or if the mut visitor is just too different because of the mutation