Avoid reported unsoundness for implied lifetime bounds #12471

YpeKingma · 2024-03-12T10:12:17Z

changelog: [lifetimes_bound_nested_ref]: Avoid some unsoundness for implied lifetime bounds

The lints here are unusual in that they are related to a compiler bug.
This zulip discussion was my starting point:
https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/cve-rs

In the discussion, this overview on implied bounds was mentioned:
https://github.com/rust-lang/rustc-dev-guide/blob/478a77a902f64e5128e7164e4e8a3980cfe4b133/src/traits/implied-bounds.md

and these are reported compiler bugs:

rust-lang/rust#25860
Implied bounds on nested references + variance = soundness hole
rust-lang/rust#25860 (comment)

rust-lang/rust#84591
HRTB on subtrait unsoundly provides HTRB on supertrait with weaker implied bounds

rust-lang/rust#100051
Implied bounds from projections in impl header can be unsound

One lint here suggests to add a generic lifetime bound for each function argument and return value
that is a nested reference with lifetimes, rust-lang/rust#25860 .

This generic lifetime bound is implied by this nested reference,
the nested reference lifetime should outlive the initial reference lifetime.

Without the added lifetime bound the current compiler (1.76.0) can generate unsound code,
as reported above.
However when the generic lifetime bound implied by the nested reference is added,
the compiler produces an error message when the function is used.
Therefore this lint can help to avoid the unsoundness in this case.

The other lint here is the reverse of the first one.
It suggests to delete this generic lifetime bound because it is implied.
This lint can help to clean up code, but only after the corresponding unsoundness is fixed
in the compiler.
I have added the reverse lint because of the unusual situation here.

For the other two cases
rust-lang/rust#84591 and
rust-lang/rust#100051 ,
the situation is similar: when manually adding a generic lifetime bound that is implied
by a nested reference, the compiler gives an error instead of producing unsound code.

Pending the review here, I want to continue with similar pairs of lints for these other two cases.

Is it necessary to document the error messages that the compiler gives when
the generic lifetime bounds are added in the reported examples?

rustbot · 2024-03-12T10:12:24Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Manishearth (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

@rustbot author: the review is finished, PR author should check the comments and take action accordingly
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Manishearth · 2024-03-12T10:30:30Z

r? @oli-obk would you be willing to review this?

rustbot · 2024-03-12T10:30:33Z

Failed to set assignee to oli-obk: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

oli-obk

I think this will be too noisy to use, because it's only a problem when the lifetimes are used again in other arguments and return types, and I don't actually know the details of where it will be problematic. Maybe at minimum check that the lifetimes are used again at all

oli-obk · 2024-03-12T14:26:42Z

clippy_lints/src/lifetimes_bound_nested_ref.rs

+    let TyKind::Ref(mut lifetime, mut mut_ty) = ty.kind else {
+        return implied_bounds;
+    };
+    while let TyKind::Ref(nested_lifetime, nested_mut_ty) = mut_ty.ty.kind {


these references may be nested behind other types, too (e.g. &'a (&'b i32, u32)). I'm also not sure whether references are the only things that exhibit this behaviour. There can be struct Foo<'a>(&'a ()) that then get used as &'a Foo<'b>.

also this doesn't handle type aliases. It may be easier to do this analysis on the ty datastructures instead of on the hir datastructures. You can get the ty::FnSig via cx.tcx.fn_sig(local_def_id).

also this doesn't handle type aliases. It may be easier to do this analysis on the ty datastructures instead of on the hir datastructures. You can get the ty::FnSig via cx.tcx.fn_sig(local_def_id).

I'll try and use the ty::FnSig instead of the things from hir to collect the implied bounds. In the example &'a (&'b i32, u32) I see that this will probably need recursion, and implementing that might take a while.

Having more implied bounds could add to the noise...

YpeKingma · 2024-03-12T21:00:15Z

I think this will be too noisy to use, because it's only a problem when the lifetimes are used again in other arguments and return types, and I don't actually know the details of where it will be problematic.

Adding any number of implicit lifetime bounds is correct (but should not be necessary, see the reverse lint.)
When this happens too often it could become noisy, and then this lint might be extended to automatically apply the suggested addition.

I could try check how often this occurs by using cargo dogfood. I suppose that includes the source code of clippy,
and I see plenty of lifetimes in there.

The unknown problem in this case is the possible unsoundness when an implicit lifetimes bound is added and the compiler does not complain about the new code.

Maybe at minimum check that the lifetimes are used again at all

Checking for lifetimes that are not used again at all sounds like another lint, but I may misunderstand this.
I suppose this can occur for pub functions/... that are not used elsewhere.

In the reported pieces of code, after adding an implicit lifetime the compiler gives an error at later use.
A check for the possibility of a later compiler error could be added in the clippy run, but that might lead to false negatives when this check is not implemented correctly.

oli-obk · 2024-03-12T21:19:09Z

Checking for lifetimes that are not used again at all sounds like another lint, but I may misunderstand this.

I mean to not emit the lint unless the lifetime appears twice in the signature.

As far as I understood it, that is how you can get the unsoundness. Not with a function that's just missing an implied bound on two lifetimes, but additionally has one (or both?) Lifetimes again elsewhere in the same signature.

I don't have a strong opinion on whether to land the lint as is or improve it. I think you'd want to first run it on a few crates to see if it is useful in practice, or if it mainly asks to annotate items that don't have any soundness concerns.

It's fine to land with lots of missed situations. I just worry about lots of false alarms.

oli-obk · 2024-03-12T21:21:18Z

clippy_lints/src/lifetimes_bound_nested_ref.rs

+                    ctx,
+                    ADD_REDUNDANT_LIFETIMES_BOUND_NESTED_REF_FN,
+                    generics.span,
+                    &format!(


The one thing I think should happen before landing this is to make it a structured suggestion, so people can just rustfix their crates instead of having to manually adjust possibly hundreds of functions

I hope I can get this to work as a structured suggestion.

flip1995 · 2024-03-13T10:46:43Z

clippy_lints/src/lifetimes_bound_nested_ref.rs

@@ -0,0 +1,222 @@
+/// Lints to help dealing with unsoundness due to a compiler bug described here:


Starting a thread to localize this discussion:

My question is about the motivation of including this into Clippy: If Clippy is able to detect those unsoundness issues, shouldn't this be implemented in the compiler and fix the unsoundness bugs?

One explanation for this approach that I see is, that this lint will have false positives (FPs), so implementing it in the compiler would restrict the language too much. Am I right in that assumption?

If this should be the case, putting the lint into a warn-by-default group might be hard. We definitely should run our lintcheck tool to look for FPs in popular crates.

Starting a thread to localize this discussion:

My question is about the motivation of including this into Clippy: If Clippy is able to detect those unsoundness issues, shouldn't this be implemented in the compiler and fix the unsoundness bugs?

Ideally yes, and I hope the compiler gets fixed before this is ready.
But the 25860 issue was reported in 2015...

One explanation for this approach that I see is, that this lint will have false positives (FPs), so implementing it in the compiler would restrict the language too much. Am I right in that assumption?

An implied bound is correct because it is implied by the compiler input code. Adding an implied bound is also correct, but it adds redundancy in the input code. I think there is no language restriction here.

Yea, this isn't implemented in rustc, because it would require bounds in a lot of places, while the new solver that can fix this (citation needed) is still about a year out.

I just wonder how many ppl will use this lint. I don't want you to waste time writing a complex lint that then becomes mostly unused

Manually adding the implied lifetimes bound fixes the three reported cases: the compiler then gives an error message for them. The compiler could also do this addition internally.

clippy_lints/src/lifetimes_bound_nested_ref.rs

flip1995 · 2024-03-13T10:51:33Z

clippy_lints/src/lifetimes_bound_nested_ref.rs

+    /// pub const fn lifetime_translator<'a, 'b: 'a, T>(val_a: &'a &'b (), val_b: &'b T) -> &'a T {...}
+    /// ```
+    #[clippy::version = "1.78.0"]
+    pub ADD_REDUNDANT_LIFETIMES_BOUND_NESTED_REF_FN,


Those lint names are a mouthful.

Maybe: IMPLICIT_LIFETIME_BOUNDS here and EXPLICIT_* for the lint that removes those again?

Those lint names are a mouthful.

Maybe: IMPLICIT_LIFETIME_BOUNDS here and EXPLICIT_* for the lint that removes those again?

From back to front:

The _FN suffix is there to indicate to the 25860 issue. The idea was to start off with different suffixes for the three issues but merging the lints into the same name makes them easier to use, so I'll drop the suffix.

LIFETIME_BOUNDS is easier to read by not accurate: the lint gives an error message for a single bound,
and each bound has two lifetimes.

I'll change the lint names to use IMPLICIT instead of ADD_REDUNDANT, and similarly for the explicit and remove redundant.

LIFETIME_BOUNDS is easier to read by not accurate

Please refer to the lint naming conventions, 2. paragraph:

The basic rule is: the lint name should make sense when read as "allow lint-name" or "allow lint-name items". For example, "allow deprecated items" and "allow dead_code" makes sense, while "allow unsafe_block" is ungrammatical (should be plural).

I think you can keep the _FN suffix to separate those lints, but I'm not convinced that the NESTED_REF really has to be part of the lint name.

YpeKingma · 2024-03-13T13:18:53Z

Checking for lifetimes that are not used again at all sounds like another lint, but I may misunderstand this.

I mean to not emit the lint unless the lifetime appears twice in the signature.

As far as I understood it, that is how you can get the unsoundness. Not with a function that's just missing an implied bound on two lifetimes, but additionally has one (or both?) Lifetimes again elsewhere in the same signature.

I'll try and do that for the 25860 issue.
For the other two issues a function signature may not be sufficient to detect this.

I don't have a strong opinion on whether to land the lint as is or improve it. I think you'd want to first run it on a few crates to see if it is useful in practice, or if it mainly asks to annotate items that don't have any soundness concerns.

It's fine to land with lots of missed situations. I just worry about lots of false alarms.

I agree this requires careful treading.

bors · 2024-03-17T08:26:31Z

☔ The latest upstream changes (presumably #12451) made this pull request unmergeable. Please resolve the merge conflicts.

rustbot · 2024-03-17T20:40:20Z

There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

You can start a rebase with the following commands:

$ # rebase
$ git rebase -i master
$ # delete any merge commits in the editor that appears
$ git push --force-with-lease

The following commits are merge commits:

7f51e81

rustbot · 2024-03-17T20:58:19Z

There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

You can start a rebase with the following commands:

$ # rebase
$ git rebase -i master
$ # delete any merge commits in the editor that appears
$ git push --force-with-lease

The following commits are merge commits (since this message was last posted):

8f11751

YpeKingma · 2024-03-17T22:07:44Z

Well, after some back and forth with CI/CD I don´t know the root cause of the last error in the Clippy Test / base (pull_request) above. It's in the code docs, so I'll leave it at that for now.

The actual code is for issue 25860:

I renamed the lints to IMPLICIT_LIFETIMES_BOUND_NESTED_REF and EXPLICIT_LIFETIMES_BOUND_NESTED_REF.
Still a mouth full, but a bit shorter than earlier with ADD_IMPLIED.... and REMOVE_EXPLICIT... .

The implicit lifetime bounds are now derived from the fn_sig() as suggested.
The recursion on Ty for this worked out well, but perhaps it can be done by a visitor instead,
see collect_nested_ref_implied_bounds().

For the rest, I changed the lifetime bound pair struct to use String for simplicity.
This assumes that the lifetime names are unique, i.e. they should be taken from a single scope.

Not yet done:

Check that a lifetime bound has a lifetime that occurs at least twice in the function signature,
before reporting the bound.
Should that check depend on which lifetime (long/outlived) is involved?

Make the lints a structured suggestion to allow automatic fixing, both ways.
This will need better dealing with the source spans, currently on the generics span is used.
The source span for an implied nested reference could also be useful in the error message.

Add test cases to have better coverage for the Ty recursion: tuple, array and slice types.

Remaining cases for lints:

// from https://github.com/rust-lang/rust/issues/100051
impl<'a: 'b, 'b> Extend<'a, 'b> for <&'b &'a () as Trait>::Type {...}
// impl<'a, 'b> Extend<'a, 'b> for <&'b &'a () as Trait>::Type {...}


// from https://github.com/rust-lang/rust/issues/84591
impl<'a: 'b, 'b> Subtrait<'a, 'b, &'b &'a ()> for MyStruct {}
// impl<'a, 'b> Subtrait<'a, 'b, &'b &'a ()> for MyStruct {}

How much code documentation is needed?

YpeKingma · 2024-03-18T21:01:47Z

The commits today for the other two went faster than I expected. Please include them for review.

YpeKingma · 2024-03-20T15:51:03Z

cargo dev dogfood does not pass here, fixing...

YpeKingma · 2024-03-20T22:06:47Z

cargo uitest fails nicely on useless_asref.rs line 23:

impl<'a, 'b, 'c> AsRef<&'a &'b &'c MoreRef> for MoreRef

with two error messages for missing implied bounds 'b: 'a and 'c: 'b.
I don't think that needs to be corrected.

I also made a local version with the IMPLICIT* lint in the category suspicious instead of nursery.
cargo lintcheck with local version did not make the clippy::implicit-lifetimes-bound-nested-ref lint show up in the stats,
so it could be that there is no noise from there.

YpeKingma · 2024-03-21T10:04:12Z

A possible way to assign these lints to categories over longer periods of time, several releases around the compiler fix for the related unsoundness:

implicit-lifetimes-bound-nested-ref : first nursery to try, then pedantic, then (may be) suspicious, then compiler fix, then deprecated.
explicit-lifetimes-bound-nested-ref : first nursery to wait, then compiler fix, then complexity.

The pedantic category fits nicely with the implication here.

YpeKingma · 2024-03-21T19:50:16Z

The Clippy Test / base is failing because I missed a cargo uibless. Fixing...

YpeKingma · 2024-03-21T19:57:52Z

Rustc was updated to 1.77.0 today, and I'm using it now.
How do I deal with this update here?
Can I merge master into the lifetimes_bound_nested_ref branch, or should I squash the update here?

flip1995 · 2024-03-22T10:57:45Z

Running this on the top 500 crates by downloads, triggered the lint 4 times:

clippy 0.1.78 (8732557 2024-03-20)

Reports

target/lintcheck/sources/clap_builder-4.5.2/src/parser/features/suggestions.rs:38:32 clippy::implicit_lifetimes_bound_nested_ref "missing lifetime bound declation: '_: '_"
target/lintcheck/sources/httparse-1.8.0/src/lib.rs:903:22 clippy::implicit_lifetimes_bound_nested_ref "missing lifetime bound declation: '_: '_"
target/lintcheck/sources/httparse-1.8.0/src/lib.rs:916:27 clippy::implicit_lifetimes_bound_nested_ref "missing lifetime bound declation: 'b: 'a"
target/lintcheck/sources/httparse-1.8.0/src/lib.rs:936:29 clippy::implicit_lifetimes_bound_nested_ref "missing lifetime bound declation: '_: '_"

Stats:

lint	count
clippy::implicit_lifetimes_bound_nested_ref	4

I don't have the time to look into those rn.

YpeKingma · 2024-03-22T14:41:44Z

Running this on the top 500 crates by downloads, triggered the lint 4 times:

...

Thank you.

The reported bounds with empty lifetime names indicate a bug here.
I'll get these two crates to use them as test cases, and then:

try and recompile after manually adding this reported bound: httparse-1.8.0/src/lib.rs:916:27
investigate the reporting of empty lifetime names.

YpeKingma · 2024-03-22T15:02:41Z

This is most likely the source code for the reported missing bounds (currently at line 1027 in src/lib.rs of the httparse crate):

unsafe fn deinit_slice_mut<'a, 'b, T>(s: &'a mut &'b mut [T]) -> &'a mut &'b mut [MaybeUninit<T>] {
    let s: *mut &mut [T] = s;
    let s = s as *mut &mut [MaybeUninit<T>];
    &mut *s
}

Since the argument and return type have the same reference structure, I would not expect this to cause unsoundness.

Shall I add a condition for the lint here that the implied bounds from input arguments and from the return type are not the same?

flip1995 · 2024-03-22T16:06:41Z

Shall I add a condition for the lint here that the implied bounds from input arguments and from the return type are not the same?

If it can't cause unsoundness issues and your motivated to add a check for it, I'd say sure, go for it.

Sidenote: there's a typo in the error message: declation

YpeKingma · 2024-03-22T16:24:16Z

This is most likely the source code for the reported missing bounds (currently at line 1027 in src/lib.rs of the httparse crate):
unsafe fn deinit_slice_mut<'a, 'b, T>(s: &'a mut &'b mut [T]) -> &'a mut &'b mut [MaybeUninit<T>] {
    let s: *mut &mut [T] = s;
    let s = s as *mut &mut [MaybeUninit<T>];

I added the implied bound manually on its current master, and it still compiles and tests cleanly:

ype@v110:~/gitrepos/httparse$ git diff -U0
diff --git a/src/lib.rs b/src/lib.rs
index 3232852..457f225 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -1027 +1027 @@ fn parse_headers_iter<'a>(
-unsafe fn deinit_slice_mut<'a, 'b, T>(s: &'a mut &'b mut [T]) -> &'a mut &'b mut [MaybeUninit<T>] {
+unsafe fn deinit_slice_mut<'a, 'b: 'a, T>(s: &'a mut &'b mut [T]) -> &'a mut &'b mut [MaybeUninit<T>] {
&mut *s
> }
> ```

xFrednet · 2024-06-25T16:11:07Z

Ping @flip1995, do you still want to give this PR a review or reroll?

flip1995 · 2024-06-26T16:21:53Z

Let's reroll. I enjoyed the nice weather over the weekend instead and won't have time this week either.

r? clippy

I really want to give this another look though. But merging shouldn't be blocked by me.

Manishearth · 2024-06-26T16:46:38Z

r? clippy

also rerolling, tad busy today

YpeKingma · 2024-07-10T20:42:28Z

On today's push: see the 3 commit messages.

Only one CI failure is left, and it indicates an unclosed delimiter for the docs of the main function. However I still cannot find the root cause for this failure.

rustbot · 2024-10-16T12:05:32Z

There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

You can start a rebase with the following commands:

$ # rebase
$ git pull --rebase https://github.com/rust-lang/rust-clippy.git master
$ git push --force-with-lease

The following commits are merge commits:

…Use(). Change the comment on GenericBound::Outlives().

YpeKingma · 2024-10-16T12:20:28Z

Today's push: no functional changes, only updates to follow the master branch.

Meanwhile there were some comments on the unsoundness bugs mentioned above.

I think the best next step would be to build this into the compiler to fix these bugs.
But I have no idea how to start with that, and I don't know how these recent comments relate to that.

rustbot assigned Manishearth Mar 12, 2024

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Mar 12, 2024

oli-obk suggested changes Mar 12, 2024

View reviewed changes

oli-obk reviewed Mar 12, 2024

View reviewed changes

flip1995 reviewed Mar 13, 2024

View reviewed changes

rustbot added has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Mar 17, 2024

YpeKingma requested a review from oli-obk March 17, 2024 22:14

YpeKingma changed the title ~~Avoid some unsoundness for implied lifetime bounds~~ Avoid reported unsoundness for implied lifetime bounds Mar 22, 2024

rustbot assigned Manishearth and unassigned flip1995 Jun 26, 2024

rustbot assigned Jarcho and unassigned Manishearth Jun 26, 2024

YpeKingma force-pushed the lifetimes_bound_nested_ref branch from 3f0f0dc to bb6d11d Compare July 10, 2024 20:11

YpeKingma force-pushed the lifetimes_bound_nested_ref branch from 865401c to 979051b Compare October 16, 2024 12:05

rustbot added has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Oct 16, 2024

Ype Kingma added 13 commits October 16, 2024 14:07

Updated to master, resolved a minor conflict, fixed a typo

d6d29df

Typo in comment

e37d681

Move unused capturing args from TyKind::ImplTrait() to GenericBound::…

3d63aca

…Use(). Change the comment on GenericBound::Outlives().

Add some code docs, improve a comment, minor reformat

b806bda

Use derived lexicographic ordering for BoundLftPair

8bd90c7

Rename a function to follow api guidelines

96e2592

More code docs, remove unused generics_span

aff676c

Some renames and added code docs

ad8213f

Correct docs mentioning impl block to trait impl decl

18bab34

Use Span.to() to replace spans_merge()

b3497a2

Dogfood: add backticks

a3b4021

cargo dev update_lints and fmt, move use stmts to start of source file

1c65bda

Another cargo dev fmt

ddf9aa9

YpeKingma force-pushed the lifetimes_bound_nested_ref branch from 979051b to ddf9aa9 Compare October 16, 2024 12:09

rustbot removed has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Oct 16, 2024

		@@ -0,0 +1,222 @@
		/// Lints to help dealing with unsoundness due to a compiler bug described here:

Avoid reported unsoundness for implied lifetime bounds #12471

Are you sure you want to change the base?

Avoid reported unsoundness for implied lifetime bounds #12471

Conversation

YpeKingma commented Mar 12, 2024

rustbot commented Mar 12, 2024

Manishearth commented Mar 12, 2024

rustbot commented Mar 12, 2024

oli-obk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

YpeKingma Mar 12, 2024 • edited Loading

Choose a reason for hiding this comment

YpeKingma commented Mar 12, 2024

oli-obk commented Mar 12, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

YpeKingma Mar 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

YpeKingma commented Mar 13, 2024

bors commented Mar 17, 2024

rustbot commented Mar 17, 2024

rustbot commented Mar 17, 2024

YpeKingma commented Mar 17, 2024 • edited Loading

YpeKingma commented Mar 18, 2024

YpeKingma commented Mar 20, 2024

YpeKingma commented Mar 20, 2024 • edited Loading

YpeKingma commented Mar 21, 2024 • edited Loading

YpeKingma commented Mar 21, 2024

YpeKingma commented Mar 21, 2024

flip1995 commented Mar 22, 2024 • edited Loading

Reports

Stats:

YpeKingma commented Mar 22, 2024

YpeKingma commented Mar 22, 2024

flip1995 commented Mar 22, 2024

YpeKingma commented Mar 22, 2024 • edited Loading

xFrednet commented Jun 25, 2024

flip1995 commented Jun 26, 2024

Manishearth commented Jun 26, 2024

YpeKingma commented Jul 10, 2024 • edited Loading

rustbot commented Oct 16, 2024

YpeKingma commented Oct 16, 2024 • edited Loading

YpeKingma Mar 12, 2024 •

edited

Loading

YpeKingma Mar 13, 2024 •

edited

Loading

YpeKingma commented Mar 17, 2024 •

edited

Loading

YpeKingma commented Mar 20, 2024 •

edited

Loading

YpeKingma commented Mar 21, 2024 •

edited

Loading

flip1995 commented Mar 22, 2024 •

edited

Loading

YpeKingma commented Mar 22, 2024 •

edited

Loading

YpeKingma commented Jul 10, 2024 •

edited

Loading

YpeKingma commented Oct 16, 2024 •

edited

Loading