Rust for Linux List
 help / color / mirror / Atom feed
From: "Eliot Courtney" <ecourtney@nvidia.com>
To: "Danilo Krummrich" <dakr@kernel.org>,
	<gregkh@linuxfoundation.org>, <rafael@kernel.org>,
	<acourbot@nvidia.com>, <aliceryhl@google.com>,
	<david.m.ertman@intel.com>, <ira.weiny@intel.com>,
	<leon@kernel.org>, <viresh.kumar@linaro.org>,
	<m.wilczynski@samsung.com>, <ukleinek@kernel.org>,
	<bhelgaas@google.com>, <kwilczynski@kernel.org>,
	<abdiel.janulgue@gmail.com>, <robin.murphy@arm.com>,
	<markus.probst@posteo.de>, <ojeda@kernel.org>, <boqun@kernel.org>,
	<gary@garyguo.net>, <bjorn3_gh@protonmail.com>,
	<lossin@kernel.org>, <a.hindborg@kernel.org>, <tmgross@umich.edu>,
	<igor.korotin@linux.dev>, <daniel.almeida@collabora.com>,
	<pcolberg@redhat.com>
Cc: <driver-core@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
	<nova-gpu@lists.linux.dev>, <dri-devel@lists.freedesktop.org>,
	<linux-pm@vger.kernel.org>, <linux-pwm@vger.kernel.org>,
	<linux-pci@vger.kernel.org>, <rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH v3 16/27] rust: types: add `ForLt` trait for higher-ranked lifetime support
Date: Tue, 19 May 2026 15:02:43 +0900	[thread overview]
Message-ID: <DIMFBTLBNISD.W92F9DWEFSX@nvidia.com> (raw)
In-Reply-To: <20260517000149.3226762-17-dakr@kernel.org>

On Sun May 17, 2026 at 9:01 AM JST, Danilo Krummrich wrote:
> From: Gary Guo <gary@garyguo.net>
>
> There are a few cases, e.g. when dealing with data referencing each other,
> one might want to write code that are generic over lifetimes. For example,
> if you want 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 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 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]
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
> ---

> +trait TypeExt {
> +    fn expand_elided_lifetime(&self, explicit_lt: &Lifetime) -> Type;
> +    fn replace_lifetime(&self, src: &Lifetime, dst: &Lifetime) -> Type;
> +    fn has_lifetime(&self, lt: &Lifetime) -> bool;
> +}
> +
> +impl TypeExt for Type {
> +    fn expand_elided_lifetime(&self, explicit_lt: &Lifetime) -> Type {
> +        struct ElidedLifetimeExpander<'a>(&'a Lifetime);
> +
> +        impl VisitMut for ElidedLifetimeExpander<'_> {
> +            fn visit_lifetime_mut(&mut self, lifetime: &mut Lifetime) {
> +                // Expand explicit `'_`
> +                if lifetime.ident == "_" {
> +                    *lifetime = self.0.clone();
> +                }
> +            }
> +
> +            fn visit_type_reference_mut(&mut self, reference: &mut syn::TypeReference) {
> +                syn::visit_mut::visit_type_reference_mut(self, reference);
> +
> +                if reference.lifetime.is_none() {
> +                    reference.lifetime = Some(self.0.clone());
> +                }
> +            }
> +        }
> +
> +        let mut ret = self.clone();
> +        ElidedLifetimeExpander(explicit_lt).visit_type_mut(&mut ret);
> +        ret
> +    }
> +
> +    fn replace_lifetime(&self, src: &Lifetime, dst: &Lifetime) -> Type {
> +        struct LifetimeReplacer<'a>(&'a Lifetime, &'a Lifetime);
> +
> +        impl VisitMut for LifetimeReplacer<'_> {
> +            fn visit_lifetime_mut(&mut self, lifetime: &mut Lifetime) {
> +                if lifetime.ident == self.0.ident {
> +                    *lifetime = self.1.clone();
> +                }
> +            }
> +        }
> +
> +        let mut ret = self.clone();
> +        LifetimeReplacer(src, dst).visit_type_mut(&mut ret);
> +        ret
> +    }
> +
> +    fn has_lifetime(&self, lt: &Lifetime) -> bool {
> +        struct HasLifetime<'a>(&'a Lifetime, bool);
> +
> +        impl Visit<'_> for HasLifetime<'_> {
> +            fn visit_lifetime(&mut self, lifetime: &Lifetime) {
> +                if lifetime.ident == self.0.ident {
> +                    self.1 = true;
> +                }
> +            }
> +        }
> +
> +        let mut visitor = HasLifetime(lt, false);
> +        visitor.visit_type(self);
> +        visitor.1
> +    }
> +}
> +
> +struct Prover<'a>(&'a Lifetime, Vec<&'a Type>);
> +
> +impl<'a> Prover<'a> {
> +    /// Prove that `ty` is covariant over `'lt`.
> +    ///
> +    /// This also needs to prove that it'll be wellformed for any instance of `'lt`.
> +    /// It can be assumed that `ty` will be wellformed if `'lt` is substituted to `'static`.
> +    fn prove(&mut self, ty: &'a Type) {
> +        match ty {
> +            Type::Paren(ty) => self.prove(&ty.elem),
> +            Type::Group(ty) => self.prove(&ty.elem),
> +
> +            // No lifetime involved
> +            Type::Never(_) => {}
> +
> +            // `[T; N]` and `[T]` is covariant over `T`.
> +            Type::Array(ty) => self.prove(&ty.elem),
> +            Type::Slice(ty) => self.prove(&ty.elem),
> +
> +            Type::Tuple(ty) => {
> +                for elem in &ty.elems {
> +                    self.prove(elem);
> +                }
> +            }
> +
> +            // `*const T` is covariant over `T`
> +            Type::Ptr(ty) if ty.const_token.is_some() => self.prove(&ty.elem),
> +
> +            // `&T` is covariant over `T` and lifetime.
> +            //
> +            // Note that if we encounter `&'other_lt T`, then we still need to make sure the type
> +            // is wellformed if `T` involves `&'lt`, so we defer to the compiler.
> +            //
> +            // This is to block cases like `ForLt!(for<'a> &'static &'a u32)`, as the presence of
> +            // the type implies `'a: 'static` but this is unsound.
> +            Type::Reference(ty)
> +                if ty.mutability.is_none() && ty.lifetime.as_ref() == Some(self.0) =>
> +            {
> +                self.prove(&ty.elem)
> +            }
> +
> +            // `&[mut] T` is covariant over lifetime.
> +            // In case we have `&[mut] NoLifetime`, we don't need to do additional checks.
> +            Type::Reference(ty) if !ty.elem.has_lifetime(self.0) => (),
> +
> +            // No mention of lifetime at all, no need to perform compiler check.
> +            ty if !ty.has_lifetime(self.0) => (),

This treats macros as not having a lifetime, but it allows this which is
not covariant for 'a IIUC:

```
trait Trait {}

macro_rules! asdf {
  () => { dyn Trait };
}

type NotCovariant = ForLt!(for<'a> &'a mut asdf!());
```

And you can get rid of the macro too:

```
type NotCovariant = ForLt!(for<'a> &'a mut dyn Trait);
```

These are not covariant because dyn Trait has an elided +'a lifetime.

I feel that the syntactic checking is kinda difficult to get right since
it would need to handle all ways lifetimes can be elided now and in the
future.

Would it be that bad to always emit the proofs?


  reply	other threads:[~2026-05-19  6:02 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-17  0:00 [PATCH v3 00/27] rust: device: Higher-Ranked Lifetime Types for device drivers Danilo Krummrich
2026-05-17  0:00 ` [PATCH v3 01/27] rust: alloc: remove `'static` bound on `ForeignOwnable` Danilo Krummrich
2026-05-18 14:42   ` Alexandre Courbot
2026-05-17  0:00 ` [PATCH v3 02/27] rust: driver: move 'static bounds to constructor Danilo Krummrich
2026-05-18 14:42   ` Alexandre Courbot
2026-05-17  0:00 ` [PATCH v3 03/27] rust: driver: decouple driver private data from driver type Danilo Krummrich
2026-05-17 14:32   ` Danilo Krummrich
2026-05-19 12:47     ` Gary Guo
2026-05-18 14:43   ` Alexandre Courbot
2026-05-17  0:00 ` [PATCH v3 04/27] rust: driver core: drop drvdata before devres release Danilo Krummrich
2026-05-18 14:45   ` Alexandre Courbot
2026-05-19 12:47   ` Gary Guo
2026-05-17  0:00 ` [PATCH v3 05/27] rust: pci: implement Sync for Device<Bound> Danilo Krummrich
2026-05-18 14:46   ` Alexandre Courbot
2026-05-19 13:01   ` Gary Guo
2026-05-17  0:00 ` [PATCH v3 06/27] rust: platform: " Danilo Krummrich
2026-05-18 14:46   ` Alexandre Courbot
2026-05-19 13:01   ` Gary Guo
2026-05-17  0:00 ` [PATCH v3 07/27] rust: auxiliary: " Danilo Krummrich
2026-05-18 14:47   ` Alexandre Courbot
2026-05-19 13:02   ` Gary Guo
2026-05-17  0:00 ` [PATCH v3 08/27] rust: usb: " Danilo Krummrich
2026-05-18 14:47   ` Alexandre Courbot
2026-05-19 13:02   ` Gary Guo
2026-05-17  0:00 ` [PATCH v3 09/27] rust: device: " Danilo Krummrich
2026-05-18 14:48   ` Alexandre Courbot
2026-05-19 13:02   ` Gary Guo
2026-05-17  0:00 ` [PATCH v3 10/27] rust: pci: make Driver trait lifetime-parameterized Danilo Krummrich
2026-05-18 14:53   ` Alexandre Courbot
2026-05-18 15:36   ` Gary Guo
2026-05-18 16:10     ` Danilo Krummrich
2026-05-19  4:52   ` Eliot Courtney
2026-05-19 10:39     ` Danilo Krummrich
2026-05-19 11:48       ` Gary Guo
2026-05-19 12:36         ` Danilo Krummrich
2026-05-17  0:00 ` [PATCH v3 11/27] rust: platform: " Danilo Krummrich
2026-05-18 14:55   ` Alexandre Courbot
2026-05-17  0:01 ` [PATCH v3 12/27] rust: auxiliary: " Danilo Krummrich
2026-05-18 15:39   ` Alexandre Courbot
2026-05-17  0:01 ` [PATCH v3 13/27] rust: usb: " Danilo Krummrich
2026-05-18 15:40   ` Alexandre Courbot
2026-05-17  0:01 ` [PATCH v3 14/27] rust: i2c: " Danilo Krummrich
2026-05-18 15:41   ` Alexandre Courbot
2026-05-17  0:01 ` [PATCH v3 15/27] rust: driver: update module documentation for GAT-based Data type Danilo Krummrich
2026-05-18 15:46   ` Alexandre Courbot
2026-05-17  0:01 ` [PATCH v3 16/27] rust: types: add `ForLt` trait for higher-ranked lifetime support Danilo Krummrich
2026-05-19  6:02   ` Eliot Courtney [this message]
2026-05-19 11:23     ` Gary Guo
2026-05-19 11:07   ` Alexandre Courbot
2026-05-19 11:39     ` Gary Guo
2026-05-19 13:03       ` Danilo Krummrich
2026-05-19 13:34         ` Miguel Ojeda
2026-05-17  0:01 ` [PATCH v3 17/27] rust: auxiliary: generalize Registration over ForLt Danilo Krummrich
2026-05-19  7:56   ` Eliot Courtney
2026-05-19 10:39     ` Danilo Krummrich
2026-05-19 11:20       ` Gary Guo
2026-05-19 16:45   ` Gary Guo
2026-05-17  0:01 ` [PATCH v3 18/27] samples: rust: rust_driver_auxiliary: showcase lifetime-bound registration data Danilo Krummrich
2026-05-19  6:52   ` Eliot Courtney
2026-05-19 15:48   ` Gary Guo
2026-05-17  0:01 ` [PATCH v3 19/27] rust: pci: make Bar lifetime-parameterized Danilo Krummrich
2026-05-19  6:36   ` Eliot Courtney
2026-05-19 16:24   ` Gary Guo
2026-05-19 17:27     ` Danilo Krummrich
2026-05-17  0:01 ` [PATCH v3 20/27] rust: io: make IoMem and ExclusiveIoMem lifetime-parameterized Danilo Krummrich
2026-05-19  6:39   ` Eliot Courtney
2026-05-17  0:01 ` [PATCH v3 21/27] samples: rust: rust_driver_pci: use HRT lifetime for Bar Danilo Krummrich
2026-05-19  6:41   ` Eliot Courtney
2026-05-17  0:01 ` [PATCH v3 22/27] rust: driver-core: rename 'a lifetime to 'bound Danilo Krummrich
2026-05-19  6:42   ` Eliot Courtney
2026-05-19 16:56   ` Gary Guo
2026-05-19 17:23     ` Danilo Krummrich
2026-05-17  0:01 ` [PATCH REF v3 23/27] gpu: nova-core: " Danilo Krummrich
2026-05-17  0:01 ` [PATCH REF v3 24/27] gpu: nova-core: use lifetime for Bar Danilo Krummrich
2026-05-17  0:01 ` [PATCH REF v3 25/27] gpu: nova-core: unregister sysmem flush page from Drop Danilo Krummrich
2026-05-17  0:01 ` [PATCH REF v3 26/27] gpu: nova-core: replace ARef<Device> with &'bound Device in SysmemFlush Danilo Krummrich
2026-05-17  0:01 ` [PATCH REF v3 27/27] gpu: drm: tyr: use lifetime for IoMem Danilo Krummrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DIMFBTLBNISD.W92F9DWEFSX@nvidia.com \
    --to=ecourtney@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=abdiel.janulgue@gmail.com \
    --cc=acourbot@nvidia.com \
    --cc=aliceryhl@google.com \
    --cc=bhelgaas@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=david.m.ertman@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=driver-core@lists.linux.dev \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=igor.korotin@linux.dev \
    --cc=ira.weiny@intel.com \
    --cc=kwilczynski@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=m.wilczynski@samsung.com \
    --cc=markus.probst@posteo.de \
    --cc=nova-gpu@lists.linux.dev \
    --cc=ojeda@kernel.org \
    --cc=pcolberg@redhat.com \
    --cc=rafael@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=ukleinek@kernel.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox