Add core::ptr::assume_moved #3700

mrkajetanp · 2024-09-26T14:49:36Z

Add a helper for primitive pointer types to facilitate modifying the address of a pointer. This
mechanism is intended to enable the use of architecture features such as AArch64 Top-Byte Ignore
(TBI) to facilitate use-cases such as high-bit pointer tagging. An example application of this
mechanism would be writing a tagging memory allocator.

Rendered

ChayimFriedman2 · 2024-09-26T16:35:37Z

Is there a reason we can not just say changing the upper bits has no impact on a pointer if an appropriate tagging scheme is available, without need for additional methods?

mrkajetanp · 2024-09-26T16:43:14Z

Yes, the reason is that even if the hardware understands a particular tagging scheme, the memory model in Rust and LLVM does not. Setting a tag on a pointer, even though it has no impact on the hardware side, makes the memory model think the pointer has now been offset outside of its original allocation and thus any access to it is Undefined Behaviour.

To be able to do this we need a helper method that simulates a "realloc" from the untagged address to the tagged address to make the memory model happy.
Specifically, we need the helper method to return a pointer that LLVM IR will annotate as noalias.
Relevant section from the linked LLVM doc:

On function return values, the noalias attribute indicates that the function acts like a system memory allocation function, returning a pointer to allocated storage disjoint from the storage for any other object accessible to the caller.

RalfJung · 2024-09-26T17:17:40Z

Cc @rust-lang/opsem

lolbinarycat · 2024-09-27T21:58:35Z

these should probably be associated functions, not methods.

also, this seems to ignore another type of pointer tagging, often used by interpreters, where the bottom bits (otherwise always zero because of alignment) are used to tag the type of the object.

RalfJung · 2024-09-29T17:41:16Z

Is there a reason we can not just say changing the upper bits has no impact on a pointer if an appropriate tagging scheme is available, without need for additional methods?

This question should indeed be answered in the RFC text, not just in the discussion thread.

(This RFC could have benefited from a pre-RFC phase, posting it on the forum to get some feedback to ensure that it has all the expected details.)

RalfJung

Thanks for posting the RFC! However, I think it wasn't quite ready yet. Here's some first feedback. This RFC is still lacking most of the relevant details, so I didn't proceed beyond the reference-level section.

RalfJung · 2024-09-29T17:29:11Z

text/3700-ptr-tag-helpers.md

+# Summary
+[summary]: #summary
+
+Add helper methods on primitive pointer types to facilitate getting and setting the tag of a pointer.


The term "tag of a pointer" means a lot of different things, and often it means something different from how you are using the term here. So the RFC should clarify the terminology it uses. This is, AFAIK, not meant to be a general pointer tagging mechanism. No RFC is even needed for that. It is specific for working with hardware that ignores certain bits of a pointer.

The thinking is that hardware that ignores certain bits of a pointer is only relevant if you're setting those bits to some values, i.e. in the context of pointer tagging. Thus, the way to add support for such hardware is through a mechanism for pointer tagging. Does that reasoning make sense?

This is still a bit of an open question, there are several directions we could go with this. The tricky part is that different architectures have support for something similar, but the details (which exact bits are ignored) may vary.
On that account I'm not sure whether it'd be better to try and make a general high-bit pointer tagging mechanism that could be used across architectures, or whether it'd be better to just upstream e.g. aarch64-specific functions into core_arch and maybe then think about a generic one that just calls into those depending on the platform.
I don't really have very strong opinions here.

I'm just pointing out the RFC is written in a confusing way. I would suggest to make it very targeted specifically for "supporting hardware that ignores some bits in a pointer", rather than general pointer tagging. This should become clear already in the summary and the first paragraph of the motivation.

RalfJung · 2024-09-29T17:34:24Z

text/3700-ptr-tag-helpers.md

+the lower 48 bits, leaving higher bits unused. The remaining bits are for the most part used to
+distinguish userspace pointers (0x00) from kernelspace pointers (0xff).
+Certain architectures provide extensions, such as TBI on AArch64, that allow programs to make use of
+those unused bits to insert custom metadata into the pointer.


To be clear, userspace can already do that without hardware support, trivially. By masking out those bots for each load. The hardware feature just makes this slightly more efficient.

I find the introduction to be a bit confusing due to this.

RalfJung · 2024-09-29T17:36:02Z

text/3700-ptr-tag-helpers.md

+Currently, Rust does not acknowledge TBI and related architecture extensions that enable the use of
+tagged pointers. This could potentially cause issues in cases such as working with TBI-enabled C/C++
+components over FFI, or when writing a tagging memory allocator.


Suggested change

Currently, Rust does not acknowledge TBI and related architecture extensions that enable the use of

tagged pointers. This could potentially cause issues in cases such as working with TBI-enabled C/C++

components over FFI, or when writing a tagging memory allocator.

Currently, Rust does not support directly using TBI and related architecture extensions that simplify the use of

tagged pointers. This could potentially cause issues in cases such as working with TBI-enabled C/C++

components over FFI, or when writing a tagging memory allocator.

RalfJung · 2024-09-29T17:37:04Z

text/3700-ptr-tag-helpers.md

+Certain architectures provide extensions, such as TBI on AArch64, that allow programs to make use of
+those unused bits to insert custom metadata into the pointer.
+
+Currently, Rust does not acknowledge TBI and related architecture extensions that enable the use of


The RFC should explain what the problem with the use of these extensions in Rust is.

Also, it is very odd to see interop with C/C++ as the motivation here, given that those languages do not support TBI either (which is another relevant fact the RFC should mention).

Well they don't support it "fully" on a language level, as in you can't just tag arbitrary pointers with no issues, but they sort of do in that there are currently C/C++ components running in production that operate on TBI-enabled pointers.
I want to make it possible to, say, write a custom allocator which internally just calls malloc, puts some tag in the pointer it got from malloc and then returns that pointer to the user.

I don't doubt there's C/C++ code in production that causes UB and works anyway, but since we are going for a UB-free approach here as we always do, it is not a fair comparison to claim that C/C++ already supports this in a way Rust wouldn't.

RalfJung · 2024-09-29T17:37:41Z

text/3700-ptr-tag-helpers.md

+```
+assert!(ptr.tag() == 0);
+let tagged_ptr = unsafe { ptr.with_tag(63) };
+assert!(tagged_ptr.tag() == 63);


The guide-level explanation should give a guide for how to think about these functions and what they do.

This is where you have to explain that tag is basically realloc. Currently, realloc suddenly appears in "drawbacks", which nobody reading the RFC will understand.

Remember that an RFC is supposed to be a self-contained document such that everyone who is reasonably well-versed in Rust but knows nothing about the particular problem domain can understand what problem the RFC is trying to solve, and how it is trying to solve it. Your RFC is missing a lot of background and explanation to make it satisfy this requirement.

RalfJung · 2024-09-29T17:38:21Z

text/3700-ptr-tag-helpers.md

+[reference-level-explanation]: #reference-level-explanation
+
+Within Rust's memory model, modifying the high bits offsets the pointer outside of the bounds of
+its original allocation, making any use of it Undefined Behaviour.


Suggested change

its original allocation, making any use of it Undefined Behaviour.

its original allocation, making any load/store with that pointer Undefined Behaviour.

"any use" is not correct, e.g. wrapping_offset or == on such a pointer are completely fine.

RalfJung · 2024-09-29T17:39:01Z

text/3700-ptr-tag-helpers.md

+caller.
+
+# Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation


This section should contain the full signature of the newly proposed methods, and their doc comments (see the existing pointer methods for how our doc comments look like), so that we have an exact description of what the proposal even is. You can't just propose two function names and leave the details for later, when the entire reason that an RFC is even needed is that those details are far from simple.

Yes for sure, the reason they're not there yet is that I wanted to ask for outside opinions before settling in on what those signatures should be and what the exact methods should actually look like. My bad that it didn't come across as intended.
The concrete part of the proposal is that we should have a function/method to set the high-bit tag of a pointer & one to retrieve it, the other details such as the name, where it should live or what it should entail are still in flux.

RalfJung · 2024-09-29T17:42:08Z

text/3700-ptr-tag-helpers.md

+[drawbacks]: #drawbacks
+
+Because the memory model we currently have is not fully compatible with memory tagging and
+tagged pointers, setting the high bits of a pointer must be done with great care in order to


That's not correct. Pointer tagging works perfectly fine and is a commonly used technique in Rust. The memory model is just not compatible with loading from a tagged pointer without first removing the tag.

That's why I wrote "not fully compatible" - you can make it work, just not as smoothly as one would like given what the hardware can support.
Besides, if you remove the tag, would that not make the result a different pointer? They won't compare equal after all.
Either way, I can clarify for sure if it's not self evident.

Diggsey · 2024-09-29T18:15:25Z

Why can't this be done by the backend?

ie. I write my code as *(ptr & mask), and then the backend optimizes that to *ptr if it's known that the CPU automatically ignores the bits that were masked out? (This has the obvious benefit that the code is automatically portable to other architectures without that feature...)

matthieu-m · 2024-10-04T17:31:38Z

To be able to do this we need a helper method that simulates a "realloc" from the untagged address to the tagged address to make the memory model happy.

Is simulating a realloc correct, though?

Consider the following code:

void *original = /*...*/;

void *copy = original;

void *tagged = realloc(original, ...);

Now, according to the semantics of realloc, it is guaranteed that tagged has no alias, and indeed this is the reason why at LLVM level the noalias attribute is specified.

However, if my understanding of TBI is correct, this is not what happens here.

Specifically, copy and tagged are alias of each others! And if codegen assumes that update through copy do not modify what tagged points to (or vice-versa), we'll have Undefined Behavior.

Am I misunderstanding TBI or noalias?

programmerjake · 2024-10-04T18:33:47Z

To be able to do this we need a helper method that simulates a "realloc" from the untagged address to the tagged address to make the memory model happy.

Is simulating a realloc correct, though?

Consider the following code:
void *original = /*...*/;

void *copy = original;

void *tagged = realloc(original, ...);
Now, according to the semantics of realloc, it is guaranteed that tagged has no alias, and indeed this is the reason why at LLVM level the noalias attribute is specified.

However, if my understanding of TBI is correct, this is not what happens here.

Specifically, copy and tagged are alias of each others! And if codegen assumes that update through copy do not modify what tagged points to (or vice-versa), we'll have Undefined Behavior.

you have UB if you try to do any accesses through original or anything derived from it, a realloc essentially marks original as deallocated memory inside the compiler. so it is still noalias since after the realloc, the only valid pointer is tagged, even though you're just changing the pointer tag.

RalfJung · 2024-10-05T09:56:03Z

@matthieu-m this model definitely makes some code UB that would be correct when using TBI in an assembly program. However, we have to impose some restrictions to make TBI compatible with higher-level language models such as Rust (and the same goes for C and C++). realloc is the best plan we came up with so far -- and yes, this means that after choosing a new tag, all previous pointers to this memory are now invalid. Including the ones that used the same tag! This operation returns a fresh provenance, and all future accesses must be done with pointers that are derived from the pointer returned by with_tag.

matthieu-m · 2024-10-05T11:00:46Z

The discrepancy caused by LLVM (and Rust) not understanding the concept of TBI is fairly unfortunate.

I think it should be noted in Future Possibilities that the choice of using a realloc-like method for now is future-compatible with LLVM and Rust gaining an understanding that only the bottom 56 bits of the pointer matter, and that when they do the constraints could be relaxed -- if we so wish -- to allow original & copy to still be valid (and aliased).

That is, while overly restrictive today, the drawback of the selected model is not painting us into a corner as far as I can see.

Diggsey · 2024-10-05T11:28:25Z

realloc is the best plan we came up with so far

Why is this better than explicitly masking off the bits and then having that mask be optimized away?

RalfJung · 2024-10-05T11:36:44Z

gaining an understanding that only the bottom 56 bits of the pointer matter,

Well, sometimes they get ignored, and sometimes all bits matter. This seems highly non-trivial, but I am not an expert on the relevant LLVM passes.

Why is this better than explicitly masking off the bits and then having that mask be optimized away?

That also sounds like an option, if LLVM supports it.

Diggsey · 2024-10-05T13:03:45Z

That also sounds like an option, if LLVM supports it.

It seems like LLVM knows about it, but doesn't currently have a pass that optimizes for it:
https://github.com/search?q=repo%3Allvm%2Fllvm-project%20UseAddressTopByteIgnored&type=code

Seems like it would make more sense to add this functionality to LLVM rather than Rust though.

mrkajetanp · 2024-10-10T12:48:18Z

(This RFC could have benefited from a pre-RFC phase, posting it on the forum to get some feedback to ensure that it has all the expected details.)

Indeed, I should have at least marked it as draft from the get-go, or started with the forum as you suggest. This was intended as a conversation starter, it's by no means a ready proposal. I'm fully expecting to re-write this with more information, just want to get some outside opinions and fresh eyes on the direction first.

mrkajetanp · 2024-10-10T13:13:25Z

Why can't this be done by the backend?

ie. I write my code as *(ptr & mask), and then the backend optimizes that to *ptr if it's known that the CPU automatically ignores the bits that were masked out? (This has the obvious benefit that the code is automatically portable to other architectures without that feature...)

That does sound like something that could be a useful LLVM pass, especially for compatibility with different platforms.
But I think that's a different aspect from the use-case that this PR is meant to support. What we want here is a "Rust-way" to do the following:

let addr = &value as *const _ as usize;
let tag = 60;
let tagged_addr = addr | (tag << 56);
let ptr = tagged_addr as *const i32;
let val = unsafe { *ptr };

The snippet above will currently compile & work "fine" on a TBI system, except that Miri will rightly complain that the code has UB. The end goal of this proposal is to create an interface for top-byte tagging that does not break the memory model. This is separate from making those always safe to dereference, for which the LLVM pass would be helpful.

Diggsey · 2024-10-10T13:26:38Z

@mrkajetanp

But I think that's a different aspect from the use-case that this PR is meant to support.

It's not different. Methods already exist to do what you are trying to do:

fn mask_addr(addr: usize) -> usize {
    addr & 0xFFFFFFFFFFFFFF
}
let tag = 60;
let tagged_ptr = (&value as *const _).map_addr(|addr| addr | (tag << 56));
let val = unsafe { *tagged_ptr.map_addr(mask_addr) };

This is completely sound under MIRI and doesn't require any extensions to the Rust abstract machine. The only bit that's missing is a compiler optimization that erases the .map_addr(mask_addr) on platforms where that is a no-op.

mrkajetanp · 2024-10-10T14:21:50Z

This is completely sound under MIRI and doesn't require any extensions to the Rust abstract machine

If I'm understanding what you're suggesting correctly, under this model the users would need to write out ptr.map_addr(mask_addr) for every single pointer access, no? Because without that even on a platform that ignores those bits Miri will complain as within the memory model ptr is currently pointing outside of its allocation.
If this was done inside some allocator wrapper (as it is currently being used in Android for instance) then every single pointer returned to the user would be UB to access unless the user explicitly masked those bits out. Surely that can't be a good approach?

mrkajetanp · 2024-10-10T15:09:31Z

@RalfJung Should I then re-write this based on the already received comments and then post on Rust Internals?

Diggsey · 2024-10-10T15:20:09Z

If this was done inside some allocator wrapper (as it is currently being used in Android for instance) then every single pointer returned to the user would be UB to access unless the user explicitly masked those bits out.

Fair enough - the proposed API seems a bit too high level for this allocator use-case though? Wouldn't the primitive operation be something like "realloc" but where you specify the target address? And there doesn't need to be an explicit tag() method, since you can always safely access the address of a pointer.

mrkajetanp · 2024-10-10T16:18:45Z

Wouldn't the primitive operation be something like "realloc" but where you specify the target address?

It certainly could be if that's the community consensus, I don't have very strong views on what the exact API should look like - my intention when posting this was to get opinions on that exact question. Next time around I'll go through Internals first, I suppose I took the request for comments term a bit too literally for how it's used here :)

And there doesn't need to be an explicit tag() method

True as well, the intent there is just for convenience. Because different architectures can use different bits for the tagging it'd make sense to have a corresponding tag() method just so that the user can set and retrieve tags without having to write code for a specific architecture.
If we just want to support something like realloc(target_addr) but for tagging then the explicit tag() method is not needed as we're leaving it up to the user to work out the specific bits to get and set anyway.

RalfJung · 2024-10-10T20:28:57Z

I also think a lower-level API that focuses on the realloc-like operation is better, but I am not a t-libs-api member. I also sadly don't have the capacity to be much further involved in this. I think I gave some good starting points for how the RFC could be improved, and clarified what we generally expect from RFCs. Posting an improved version to IRLO sounds like a good plan. :)

Diggsey · 2024-10-10T21:24:54Z

The realloc approach would also support cases where virtual memory mappings are used for a similar purpose on platforms without hardware support for pointer tagging (ie. where you map the same physical memory to two or more virtual address ranges).

RalfJung · 2024-10-11T06:10:09Z

The realloc approach would also support cases where virtual memory mappings are used for a similar purpose on platforms without hardware support for pointer tagging (ie. where you map the same physical memory to two or more virtual address ranges).

I don't think Rust will have standard APIs for manipulating page tables? ;)

I was going to say, I don't think this is ready yet for a portable API. It makes little sense to try and sketch a portable API that has exactly one target implementation. The RFC should focus in providing APIs for platform-specific capabilities, e.g. in core::arch. A portable API can be experimented with as a user crate, since some experimentation will be required before it becomes clear what a good API looks like.

programmerjake · 2024-10-11T06:47:04Z

I don't think Rust will have standard APIs for manipulating page tables? ;)

that doesn't matter if you can still use mmap or similar to make two mappings for the same piece of memory -- it would be nice if rust can handle that case.

This is kinda similar to how Rust doesn't have a std thread API on some targets (because they're #![no_std]), but Rust still needs to properly handle running code in different threads that were started by some mechanism outside of the Rust standard library (unless the target is specifically single-threaded only, such as wasm32-unknown-unknown)

RalfJung · 2024-10-11T07:20:39Z

that doesn't matter if you can still use mmap or similar to make two mappings for the same piece of memory -- it would be nice if rust can handle that case.

mmap is an opaque operation to Rust. If you use it to relocate an allocation, you can already treat it like a realloc. You just have to make sure that you stop using the old pointer after the realloc, and instead use the one returned by mmap.

programmerjake · 2024-10-11T07:56:19Z

that doesn't matter if you can still use mmap or similar to make two mappings for the same piece of memory -- it would be nice if rust can handle that case.

mmap is an opaque operation to Rust. If you use it to relocate an allocation, you can already treat it like a realloc. You just have to make sure that you stop using the old pointer after the realloc, and instead use the one returned by mmap.

i meant that you'd mmap the exact same memory to two locations and then use the realloc intrinsic to access both of them without any further mmap calls needed:
https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=27b03de9ba18d73a1e60badc1e5b3267

mrkajetanp · 2024-10-11T11:27:04Z

The realloc-like interface could be neat in that it would let us avoid all the otherwise present difficulties with making the interface portable. With a signature like say (name TBC) fn simulate_realloc<T>(mut original: *mut T, new_address: usize) -> *mut T, it would work for any target from the get-go and we wouldn't have to worry about the particular platform's tagging scheme.
Then in core::arch::aarch64 we could put something like:

fn ptr_with_top_byte<T>(ptr: *mut T, top_byte: u8) -> *mut T {
    let new_addr = ptr as usize | top_byte << 56;
    simulate_realloc(ptr, new_addr)
}

And similar for other platforms as needed. How does that sound?

mrkajetanp · 2024-10-22T10:44:21Z

I've now posted a re-written version of this here: https://internals.rust-lang.org/t/pre-rfc-core-simulate-realloc/21745

RalfJung · 2024-10-25T09:38:55Z

i meant that you'd mmap the exact same memory to two locations and then use the realloc intrinsic to access both of them without any further mmap calls needed:

Yeah, that could be done with an intrinsic like the one backing pointer tagging.

The realloc-like interface could be neat in that it would let us avoid all the otherwise present difficulties with making the interface portable. With a signature like say (name TBC) fn simulate_realloc(mut original: *mut T, new_address: usize) -> *mut T, it would work for any target from the get-go and we wouldn't have to worry about the particular platform's tagging scheme.

Yes that is roughly what I had in mind when suggesting a realloc-like interface. :)

mrkajetanp · 2024-11-11T11:54:22Z

Updated the RFC based on the discussion on internals:
https://internals.rust-lang.org/t/pre-rfc-core-simulate-realloc/21745

RalfJung · 2024-11-24T12:13:59Z

text/3700-ptr-assume-moved.md

+#[unstable(feature = "ptr_assume_moved", issue = "none")]
+#[cfg_attr(not(bootstrap), rustc_simulate_allocator)]
+#[allow(fuzzy_provenance_casts)]
+pub unsafe fn assume_moved<T>(original: *mut T, new_address: usize) -> *mut T {


Bikeshed: I find "assume" to be not a great choice here, since usually "assume(X)" means "either X is true or we have UB". But here it's actually fine for the allocation to not have moved at all.

It's more like, we are telling the AM that a move happened. I found "simulate" a better term than "assume". We could also use some other term of art like "axiomatic_move" or "abstract_move".

I think this is mostly subjective, arguments can be made for several different names. As I said in the internals thread, if someone from the libs/opsem team blesses a particular name I'm happy to just change it to that, whatever it may be. I don't have a particularly strong preference of my own.

It's also easy to rename later so the name does not have to be final in the RFC. (That should be mentioned under "open questions".)

Added that section back as requested :)

RalfJung · 2024-11-24T12:17:18Z

text/3700-ptr-assume-moved.md

+is straightforward to write a 'correct' pointer tagging implementation by simply doing a `inttoptr`
+cast inside the memory allocator implementation, be it a custom C `malloc` or using a custom C++
+`Allocator`. The goal of this effort is to create a Rust API for implementing this type of
+functionality that is guaranteed to be free of Undefined Behaviour.


FWIW doing this in the global_allocator in Rust is "probably also fine", same as in C/C++. Those are not inlined and so the compiler won't see the problematic pointer manipulations. The allocator is already special and it could be possible to fold this magic into that existing magic. (It'd still be nicer to do something proper. I just don't want there to be the impression that Rust somehow supports this less than C/C++ do.)

The main case where new language support is required is when doing this inside regular code.

mrkajetanp force-pushed the ptr-tag-helpers branch from a87b962 to af48452 Compare September 26, 2024 14:51

mrkajetanp mentioned this pull request Sep 26, 2024

core/ptr: Add simulate_realloc() rust-lang/rust#130886

Draft

RalfJung reviewed Sep 29, 2024

View reviewed changes

mrkajetanp marked this pull request as draft October 10, 2024 11:19

mrkajetanp force-pushed the ptr-tag-helpers branch from af48452 to c619803 Compare November 11, 2024 11:48

mrkajetanp changed the title ~~Add helper methods on primitive pointer types for pointer tagging~~ Add core::ptr::assume_moved Nov 11, 2024

mrkajetanp marked this pull request as ready for review November 11, 2024 11:54

davidtwco added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Nov 12, 2024

RalfJung added T-lang Relevant to the language team, which will review and decide on the RFC. T-opsem Relevant to the operational semantics team, which will review and decide on the RFC. labels Nov 18, 2024

RalfJung reviewed Nov 24, 2024

View reviewed changes

ptr-assume-moved: Add RFC

b3995b9

mrkajetanp force-pushed the ptr-tag-helpers branch from c619803 to b3995b9 Compare December 2, 2024 10:40

	its original allocation, making any use of it Undefined Behaviour.
	its original allocation, making any load/store with that pointer Undefined Behaviour.

Add core::ptr::assume_moved #3700

Are you sure you want to change the base?

Add core::ptr::assume_moved #3700

Conversation

mrkajetanp commented Sep 26, 2024 • edited Loading

ChayimFriedman2 commented Sep 26, 2024

mrkajetanp commented Sep 26, 2024

RalfJung commented Sep 26, 2024

lolbinarycat commented Sep 27, 2024

RalfJung commented Sep 29, 2024

RalfJung left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RalfJung Oct 10, 2024 • edited Loading

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

RalfJung Oct 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RalfJung Sep 29, 2024 • edited Loading

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

Diggsey commented Sep 29, 2024 • edited Loading

matthieu-m commented Oct 4, 2024

programmerjake commented Oct 4, 2024

RalfJung commented Oct 5, 2024

matthieu-m commented Oct 5, 2024

Diggsey commented Oct 5, 2024

RalfJung commented Oct 5, 2024 • edited Loading

Diggsey commented Oct 5, 2024

mrkajetanp commented Oct 10, 2024

mrkajetanp commented Oct 10, 2024

Diggsey commented Oct 10, 2024 • edited Loading

mrkajetanp commented Oct 10, 2024

mrkajetanp commented Oct 10, 2024

Diggsey commented Oct 10, 2024

mrkajetanp commented Oct 10, 2024

RalfJung commented Oct 10, 2024

Diggsey commented Oct 10, 2024

RalfJung commented Oct 11, 2024

programmerjake commented Oct 11, 2024

RalfJung commented Oct 11, 2024

programmerjake commented Oct 11, 2024 • edited Loading

mrkajetanp commented Oct 11, 2024 • edited Loading

mrkajetanp commented Oct 22, 2024

RalfJung commented Oct 25, 2024

mrkajetanp commented Nov 11, 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

mrkajetanp commented Sep 26, 2024 •

edited

Loading

RalfJung Oct 10, 2024 •

edited

Loading

RalfJung Oct 10, 2024 •

edited

Loading

RalfJung Sep 29, 2024 •

edited

Loading

Diggsey commented Sep 29, 2024 •

edited

Loading

RalfJung commented Oct 5, 2024 •

edited

Loading

Diggsey commented Oct 10, 2024 •

edited

Loading

programmerjake commented Oct 11, 2024 •

edited

Loading

mrkajetanp commented Oct 11, 2024 •

edited

Loading