@@ -23,8 +23,7 @@ mod newtype;
23
23
mod query;
24
24
mod serialize;
25
25
mod symbols;
26
- mod type_foldable;
27
- mod type_visitable;
26
+ mod traversable;
28
27
29
28
// Reads the rust version (e.g. "1.75.0") from the CFG_RELEASE env var and
30
29
// produces a `RustcVersion` literal containing that version (e.g.
@@ -81,22 +80,53 @@ decl_derive!(
81
80
[ TypeFoldable , attributes( type_foldable) ] =>
82
81
/// Derives `TypeFoldable` for the annotated `struct` or `enum` (`union` is not supported).
83
82
///
84
- /// The fold will produce a value of the same struct or enum variant as the input, with
85
- /// each field respectively folded using the `TypeFoldable` implementation for its type.
86
- /// However, if a field of a struct or an enum variant is annotated with
87
- /// `#[type_foldable(identity)]` then that field will retain its incumbent value (and its
88
- /// type is not required to implement `TypeFoldable`).
89
- type_foldable:: type_foldable_derive
83
+ /// Folds will produce a value of the same struct or enum variant as the input, with each field
84
+ /// respectively folded (in definition order) using the `TypeFoldable` implementation for its
85
+ /// type. However, if a field of a struct or of an enum variant is annotated with
86
+ /// `#[type_foldable(identity)]` then that field will retain its incumbent value (and its type
87
+ /// is not required to implement `TypeFoldable`). However use of this attribute is dangerous
88
+ /// and should be used with extreme caution: should the type of the annotated field contain
89
+ /// (now or in the future) a type that is of interest to a folder, it will not get folded (which
90
+ /// may result in unexpected, hard-to-track bugs that could result in unsoundness).
91
+ ///
92
+ /// If the annotated item has a `'tcx` lifetime parameter, then that will be used as the
93
+ /// lifetime for the type context/interner; otherwise the lifetime of the type context/interner
94
+ /// will be unrelated to the annotated type. It therefore matters how any lifetime parameters of
95
+ /// the annotated type are named. For example, deriving `TypeFoldable` for both `Foo<'a>` and
96
+ /// `Bar<'tcx>` will respectively produce:
97
+ ///
98
+ /// `impl<'a, 'tcx> TypeFoldable<TyCtxt<'tcx>> for Foo<'a>`
99
+ ///
100
+ /// and
101
+ ///
102
+ /// `impl<'tcx> TypeFoldable<TyCtxt<'tcx>> for Bar<'tcx>`
103
+ traversable:: traversable_derive:: <traversable:: Foldable >
90
104
) ;
91
105
decl_derive ! (
92
106
[ TypeVisitable , attributes( type_visitable) ] =>
93
107
/// Derives `TypeVisitable` for the annotated `struct` or `enum` (`union` is not supported).
94
108
///
95
- /// Each field of the struct or enum variant will be visited in definition order, using the
96
- /// `TypeVisitable` implementation for its type. However, if a field of a struct or an enum
97
- /// variant is annotated with `#[type_visitable(ignore)]` then that field will not be
98
- /// visited (and its type is not required to implement `TypeVisitable`).
99
- type_visitable:: type_visitable_derive
109
+ /// Each field of the struct or enum variant will be visited (in definition order) using the
110
+ /// `TypeVisitable` implementation for its type. However, if a field of a struct or of an enum
111
+ /// variant is annotated with `#[type_visitable(ignore)]` then that field will not be visited
112
+ /// (and its type is not required to implement `TypeVisitable`). However use of this attribute
113
+ /// is dangerous and should be used with extreme caution: should the type of the annotated
114
+ /// field (now or in the future) a type that is of interest to a visitor, it will not get
115
+ /// visited (which may result in unexpected, hard-to-track bugs that could result in
116
+ /// unsoundness).
117
+ ///
118
+ /// If the annotated item has a `'tcx` lifetime parameter, then that will be used as the
119
+ /// lifetime for the type context/interner; otherwise the lifetime of the type context/interner
120
+ /// will be unrelated to the annotated type. It therefore matters how any lifetime parameters of
121
+ /// the annotated type are named. For example, deriving `TypeVisitable` for both `Foo<'a>` and
122
+ /// `Bar<'tcx>` will respectively produce:
123
+ ///
124
+ /// `impl<'a, 'tcx> TypeVisitable<TyCtxt<'tcx>> for Foo<'a>`
125
+ ///
126
+ /// and
127
+ ///
128
+ /// `impl<'tcx> TypeVisitable<TyCtxt<'tcx>> for Bar<'tcx>`
129
+ traversable:: traversable_derive:: <traversable:: Visitable >
100
130
) ;
101
131
decl_derive ! ( [ Lift , attributes( lift) ] => lift:: lift_derive) ;
102
132
decl_derive ! (
0 commit comments