@@ -23,8 +23,7 @@ mod newtype;
2323mod query;
2424mod serialize;
2525mod symbols;
26- mod type_foldable;
27- mod type_visitable;
26+ mod traversable;
2827
2928// Reads the rust version (e.g. "1.75.0") from the CFG_RELEASE env var and
3029// produces a `RustcVersion` literal containing that version (e.g.
@@ -81,22 +80,53 @@ decl_derive!(
8180 [ TypeFoldable , attributes( type_foldable) ] =>
8281 /// Derives `TypeFoldable` for the annotated `struct` or `enum` (`union` is not supported).
8382 ///
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 >
90104) ;
91105decl_derive ! (
92106 [ TypeVisitable , attributes( type_visitable) ] =>
93107 /// Derives `TypeVisitable` for the annotated `struct` or `enum` (`union` is not supported).
94108 ///
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 >
100130) ;
101131decl_derive ! ( [ Lift , attributes( lift) ] => lift:: lift_derive) ;
102132decl_derive ! (
0 commit comments