Add documentation for some rustc_type_ir macros - #2939
Conversation
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
5531647 to
5efc986
Compare
|
r? @lcnr |
5efc986 to
2df844b
Compare
| ### `GenericTypeVisitable` & `TypeVisitable_Generic` | ||
|
|
||
| While ostensibly similar due to their names, they implement two different | ||
| visiting systems. | ||
|
|
||
| - `TypeVisitable_Generic` means: derive the ordinary `TypeVisitable` trait | ||
| generically over an `Interner`. | ||
| - `GenericTypeVisitable` means: derive the separate `GenericTypeVisitable` trait | ||
| used by non-nightly consumers such as rust-analyzer. | ||
|
|
||
| As such a struct or enum can derive both `TypeVisitable_Generic` and | ||
| `GenericTypeVisitable` |
There was a problem hiding this comment.
instead explain this as part of the first paragraph of the GenericTypeVisitable section?
| `rustc_type_ir` makes _heavy_ use of a few macros, in particular | ||
| - [`Lift_Generic`][lift_generic] | ||
| - [`TypeFoldable_Generic`][typefoldable_generic] | ||
| - [`TypeVisitable_Generic`][typevisitable_generic] | ||
| - [`GenericTypeVisitable`][generictypevisitable] | ||
|
|
||
| Of which primarily exist to reduce the amount of boilerplate otherwise | ||
| required to implement `TypeFoldable`, `TypeVisitable` and `Lift`. |
There was a problem hiding this comment.
| `rustc_type_ir` makes _heavy_ use of a few macros, in particular | |
| - [`Lift_Generic`][lift_generic] | |
| - [`TypeFoldable_Generic`][typefoldable_generic] | |
| - [`TypeVisitable_Generic`][typevisitable_generic] | |
| - [`GenericTypeVisitable`][generictypevisitable] | |
| Of which primarily exist to reduce the amount of boilerplate otherwise | |
| required to implement `TypeFoldable`, `TypeVisitable` and `Lift`. | |
| `rustc_type_ir` makes _heavy_ use of a few macros, in particular | |
| - [`Lift_Generic`][lift_generic] | |
| - [`TypeFoldable_Generic`][typefoldable_generic] | |
| - [`TypeVisitable_Generic`][typevisitable_generic] | |
| - [`GenericTypeVisitable`][generictypevisitable] | |
| Of which primarily exist to reduce the amount of boilerplate otherwise | |
| required to implement `TypeFoldable`, `TypeVisitable` and `Lift`. | |
| These macros are variants of the `TypeFoldable`, `TypeVisitable`, and `Lift` macros used in crates which have access to the `TyCtxt` using a `I: Interner` parameter instead of `TyCtxt`. |
|
|
||
| Derives `rustc_type_ir::GenericTypeVisitable<V>` for a struct or enum. | ||
|
|
||
| This is the non-nightly, rust-analyzer-facing generic traversal. The visitor |
There was a problem hiding this comment.
| This is the non-nightly, rust-analyzer-facing generic traversal. The visitor | |
| This a separate more general traversal trait purely used by rust-analyzer. The visitor |
…ts earlier in the doc & reword GenericTypeVisitable intro
| **quirk 3:** | ||
| The bounds are deliberately written as associated type bounds on the `Interner` | ||
| trait rather than as `where` clauses on `LiftInto`. Given only `I: LiftInto<J>`, | ||
| Rust can then treat bounds such as the following as implied: | ||
|
|
||
| ```rust | ||
| I::Ty: Lift<J, Lifted = J::Ty> | ||
| I::Const: Lift<J, Lifted = J::Const> | ||
| ``` | ||
|
|
||
| This allows `Lift_Generic` to emit the bound `I: LiftInto<J>` while still | ||
| calling `lift_to_interner` on fields of type `I::Ty`, `I::Const`, and the other | ||
| declared associated types. It also guarantees that each call produces the | ||
| destination field type expected after the derive rewrites `I::Assoc` to | ||
| `J::Assoc`. | ||
|
|
||
| Without `declare_lift_into!`, the derive would need to generate a separate bound | ||
| for every interner-associated type used by every field. If a new `Interner` | ||
| associated type is expected to work with `Lift_Generic`, it needs an appropriate | ||
| `Lift` implementation and normally needs to be included in the | ||
| `declare_lift_into!` invocation. | ||
|
|
||
| If you want to ignore a file, such as a primitive like a `u32` which can't be | ||
| lifted you can skip the field with `#[lift(ignore)]`. |
There was a problem hiding this comment.
what exactly does that mean 🤔 feels like maybe that has less to do with the derive and more generally the way Lift works. Right now the context shift from "what does derive do" to "how does Lift work" is jarring. I think for derives the explanation should generally be "perfect derive, requires X for every field, following special cases"
maybe reframe this entire section to "derived traits", and then talk about the traits, then the "what's necessary for X to impl the trait", and then some small things about the way the derive macro works?
Adds documentation for;
TypeVisitable_GenericTypeFoldable_GenericLift_GenericGenericTypeVisitableFollows a formulaic "<macro_name>, description, how to use it, What its expansion does"