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