summaryrefslogtreecommitdiff
path: root/rust/kernel/types
AgeCommit message (Collapse)Author
2026-07-11rust: types: introduce ForLt base trait for CovariantForLtDanilo Krummrich
Add a new ForLt trait as a base for CovariantForLt: - ForLt (non-unsafe): represents a type generic over a lifetime, with no covariance guarantee. - CovariantForLt (unsafe): becomes a subtrait of ForLt that additionally proves the type is covariant over its lifetime parameter, providing a safe cast_ref() method. This split allows non-covariant types (e.g. types behind a Mutex) to implement ForLt and participate in DevresLt / registration data patterns that use HRTB closures for sound access, without requiring a covariance proof that would fail to compile. Both macros share the UnsafeForLtImpl helper type, distinguished by a const generic N: ForLt! emits N = 0 (no covariance proof), CovariantForLt! emits N = 1 (with compile-time covariance proof). Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://patch.msgid.link/20260626183630.2585057-3-dakr@kernel.org [ Merge ForLt pub use, inline resolve_hrt/ty_static, add intra-doc links. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-11rust: types: rename ForLt to CovariantForLtDanilo Krummrich
Rename ForLt to CovariantForLt to prepare for the introduction of a new ForLt base trait that does not require covariance. The existing ForLt trait requires covariance, which enables the safe cast_ref() method. This rename preserves the same semantics under a more precise name, making room for a weaker ForLt trait in a subsequent commit. No functional change. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://patch.msgid.link/20260626183630.2585057-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-27rust: types: add `ForLt` trait for higher-ranked lifetime supportGary Guo
There are a few cases, e.g. when dealing with data referencing each other, one might want to write code that is generic over lifetimes. For example, if you want to take a function that takes `&'a Foo` and gives `Bar<'a>`, you can write: f: impl for<'a> FnOnce(&'a Foo) -> Bar<'a>, However, it becomes tricky when you want that function to not have a fixed `Bar`, but have it be generic again. In this case, one needs something that is generic over types that are themselves generic over lifetimes. `ForLt` provides such support. It provides a trait `ForLt` which describes a type generic over a lifetime. One may use `ForLt::Of<'a>` to get an instance of a type for a specific lifetime. For the case of cross referencing, one would almost always want the lifetime to be covariant. Therefore this is also made a requirement for the `ForLt` trait, so functions with `ForLt` trait bound can assume covariance. A macro `ForLt!()` is provided to be able to obtain a type that implements `ForLt`. For example, `ForLt!(for<'a> Bar<'a>)` would yield a type that `<TheType as ForLt>::Of<'a>` is `Bar<'a>`. This also works with lifetime elision, e.g. `ForLt!(Bar<'_>)` or for types without lifetime at all, e.g. `ForLt!(u32)`. The API design draws inspiration from the higher-kinded-types [1] crate, however a different design decision has been taken (e.g. covariance requirement) and the implementation is independent. License headers use "Apache-2.0 OR MIT" because I anticipate this to be used in pin-init crate too which is licensed as such. Link: https://docs.rs/higher-kinded-types/ [1] Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Signed-off-by: Gary Guo <gary@garyguo.net> Acked-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525202921.124698-23-dakr@kernel.org [ Handle macro_rules! invocations in the ForLt! proc macro's covariance and WF checks. Since proc macros cannot expand macro_rules!, add a visit_macro() implementation to conservatively assume macro invocations may contain lifetimes, forcing them through the compiler-assisted covariance proof. Fix a few typos in the documentation and in the commit message, add empty lines before samples, add missing periods and consistently use markdown. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>