Const-eval errors in dead functions are optimization-dependent #107503

CAD97 · 2023-01-31T08:03:42Z

I tried this code: [playground]

#![feature(inline_const)]

pub fn cause_late_error<T>() {
    const {
        panic!()
    };
}

fn main() {
    let a = 1;
    let b = 2;
    if a + b == 5 {
        cause_late_error::<()>();
    }
}

I expected to see this happen:

error[E0080]: evaluation of `cause_late_error::<()>::{constant#0}` failed
 --> src/main.rs:7:9
  |
7 |         panic!()
  |         ^^^^^^^^ the evaluated program panicked at 'explicit panic', src/main.rs:7:9
  |
  = note: this error originates in the macro `$crate::panic::panic_2021` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)

note: the above error was encountered while instantiating `fn cause_late_error::<()>`
  --> src/main.rs:13:9
   |
13 |         cause_late_error::<()>();
   |         ^^^^^^^^^^^^^^^^^^^^^^^^

Instead, this happened: it compiled without any warnings.

Meta

Playground nightly, 1.69.0-nightly (2023-01-30 001a77f)

I believe this just results from cause_late_error::<()> being determined dead by MIR analysis and thus not monomorphized. Monomorphizing all mentioned names (enough to flush middleend post-mono errors) should fundamentally resolve the issue of constant evaluation errors disappearing because of MIR-level dead code elimination.

joshtriplett · 2023-01-31T19:15:52Z

@RalfJung Is it possible to produce a similarly horrifying example as #107503 (comment) that compiles on stable today, and is optimization-dependent and DCA dependent?

RalfJung · 2023-01-31T19:22:25Z

@joshtriplett yes. It's not even that hard.

pub fn cause_late_error<T>() {
    struct S;
    impl S {
        const C: () = panic!();
    }

    S::C;
}

fn main() {
    let a = 1;
    let b = 2;
    if a + b == 5 { // changing 5 to 3 makes compilation fail
        cause_late_error::<()>();
    }
}

RalfJung · 2023-01-31T19:26:13Z

And of course that also works for @oskgo's example:

#[inline(always)]
fn falser() -> bool {
    false
}

pub fn has_late_error<T>() {
    struct S;
    impl S {
        const C: () = panic!();
    }

    S::C;
}

fn main() {
    if falser() {
        has_late_error::<()>();
    }
}

Compiles in release mode but not in debug mode.

zirconium-n · 2023-02-01T00:13:23Z

Sorry if this sounds rude, but could we just issue a crater run and push a breaking change at this point? Panic in consteval is not something stabilized for too long. We can recognize this¹ as a design mistake. Whether the code depends on something other than #[cfg(debug_assertions)] is a bit too far for me...

Unused associated const doesn't not evaluate. ↩

RalfJung · 2023-05-17T14:15:05Z

This is the same underlying issue as #106617, so we probably should close one of these in favor of the other (or open a new issue to track the collected problems). We don't monomorphize dead code, which means

since optimizations affect which code is considered dead, we do opt-dependent monomorphization
since some errors are only raised during monomorphization, we have missing errors in dead code and opt-dependent errors

All of this affects stable Rust with associated consts.

traviscross · 2023-05-23T19:32:49Z

This was mentioned over in #106617 (comment), but it's worth highlighting here that this same problem can be triggered without using const at all:

fn cause_late_error<T>() {
    cause_late_error::<((), T)>();
}

fn main() {
    let (a, b) = (1, 2);
    if a + b == 5 {
        cause_late_error::<()>();
    }
}

Playground link

RalfJung · 2023-05-31T06:02:38Z

I think there's a fairly obvious way to fix this, if someone wants to give it a shot: we basically mirror required_consts.

Add a new field required_fns to mir::Body
Extend the RequiredConstsVisitor to also collect required functions (the visitor needs a rename then)
When monomorphizing a function, we don't even have to walk the MIR body to find out which other functions need to be monomorhized recursively. We just monomorhize everything in required_fn (after applying suitable substitutions).

The big question is what the perf impact of that will be, but the only way to figure that out is to actually implement this. Any takers? :)

oli-obk · 2023-05-31T10:10:21Z

Any takers? :)

on it

Draft: monomorphize things from dead code, too This is another attempt at fixing rust-lang#107503. The previous attempt at rust-lang#112879 seems stuck in figuring out where the perf regression comes from. So here I want to take baby steps to see the impact of each step. r? `@ghost`

tmiasko · 2024-03-20T09:40:54Z

Currently we are trying to do the last step (finding all relevant non-inline functions) before monomorphization, leading to some overapproximation as in the code quoted above and an overall pretty messy structure.

The approximation is inherent to the problem since it is non-computable precisely. You can view the role of a reachability pass as a form of item collection that explores all possible instantiations of generic code. This work cannot be done by a mono item collector.

Note that the example from #107503 (comment) is optimization level dependent.

RalfJung · 2024-03-20T10:27:26Z

The approximation is inherent to the problem since it is non-computable precisely. You can view the role of a reachability pass as a form of item collection that explores all possible instantiations of generic code. This work cannot be done by a mono item collector.

I have sketched a computable strategy in my previous post. I don't see why it is necessary to explore "all possible instantiations". The way I view it, reachable_set contains some hacks that are needed because the collector itself doesn't know how to deal with inlining properly -- so codegen particularities like "if a function can be inlined and it calls private functions, those private functions must be considered reachable" leak into high-level pre-mono reachability computation.

Both mono item collection and reachable_set are reachability computations. Mono item collection has all the information it needs to compute the precise set. But unfortunately its search gets pruned eagerly by removing inline functions too early, which then means some earlier pass has to extend the root set to ensure we don't remove too many things.

EDIT: Ah... I missed the issue of a generic function calling a monomorphic internal function. You are right.

Note that the example from #107503 (comment) is optimization level dependent.

I can't reproduce that, this example fails both in debug and release builds.

RalfJung · 2024-03-20T10:30:30Z

In general this behavior of skipping a bunch of checking on dead private functions is usually quite surprising anyway. Maybe the collector should just always walk all monomorphic functions, reachable or not, in "mentioned" mode?

Though I guess that means it has to run MIR opts on them, which is work we currently avoid doing. How likely is it that people have large amounts of monomorphic functions that never get mentioned (transitively) in anything "reachable"...?

tmiasko · 2024-03-20T11:56:42Z

Note that the example from #107503 (comment) is optimization level dependent.

I can't reproduce that, this example fails both in debug and release builds.

In your example the constant happens to be evaluated by one of lint passes running on MIR. This evaluation is easily avoidable. The example below fails only with optimizations enabled:

struct Fail<T>(T);
impl<T> Fail<T> {
    const C: () = panic!();
}

pub fn f() {
    loop {}; g()
}

#[inline(never)]
fn g() {
    h::<i32>()
}

fn h<T>() {
    Fail::<T>::C;
}

RalfJung · 2024-03-20T12:47:15Z

So we have HIR-level optimizations? Where are those happening?

Or is that just the same issue as your previous example above?

RalfJung · 2024-03-20T12:51:37Z

The example below fails only with optimizations enabled:

Oh lol so this is the other way around then, the unoptimized build misses the const-eval. Wtf, how is that happening...

recursively evaluate the constants in everything that is 'mentioned' This is another attempt at fixing rust-lang#107503. The previous attempt at rust-lang#112879 seems stuck in figuring out where the [perf regression](https://perf.rust-lang.org/compare.html?start=c55d1ee8d4e3162187214692229a63c2cc5e0f31&end=ec8de1ebe0d698b109beeaaac83e60f4ef8bb7d1&stat=instructions:u) comes from. In rust-lang#122258 I learned some things, which informed the approach this PR is taking. Quoting from the new collector docs, which explain the high-level idea: ```rust //! One important role of collection is to evaluate all constants that are used by all the items //! which are being collected. Codegen can then rely on only encountering constants that evaluate //! successfully, and if a constant fails to evaluate, the collector has much better context to be //! able to show where this constant comes up. //! //! However, the exact set of "used" items (collected as described above), and therefore the exact //! set of used constants, can depend on optimizations. Optimizing away dead code may optimize away //! a function call that uses a failing constant, so an unoptimized build may fail where an //! optimized build succeeds. This is undesirable. //! //! To fix this, the collector has the concept of "mentioned" items. Some time during the MIR //! pipeline, before any optimization-level-dependent optimizations, we compute a list of all items //! that syntactically appear in the code. These are considered "mentioned", and even if they are in //! dead code and get optimized away (which makes them no longer "used"), they are still //! "mentioned". For every used item, the collector ensures that all mentioned items, recursively, //! do not use a failing constant. This is reflected via the [`CollectionMode`], which determines //! whether we are visiting a used item or merely a mentioned item. //! //! The collector and "mentioned items" gathering (which lives in `rustc_mir_transform::mentioned_items`) //! need to stay in sync in the following sense: //! //! - For every item that the collector gather that could eventually lead to build failure (most //! likely due to containing a constant that fails to evaluate), a corresponding mentioned item //! must be added. This should use the exact same strategy as the ecollector to make sure they are //! in sync. However, while the collector works on monomorphized types, mentioned items are //! collected on generic MIR -- so any time the collector checks for a particular type (such as //! `ty::FnDef`), we have to just onconditionally add this as a mentioned item. //! - In `visit_mentioned_item`, we then do with that mentioned item exactly what the collector //! would have done during regular MIR visiting. Basically you can think of the collector having //! two stages, a pre-monomorphization stage and a post-monomorphization stage (usually quite //! literally separated by a call to `self.monomorphize`); the pre-monomorphizationn stage is //! duplicated in mentioned items gathering and the post-monomorphization stage is duplicated in //! `visit_mentioned_item`. //! - Finally, as a performance optimization, the collector should fill `used_mentioned_item` during //! its MIR traversal with exactly what mentioned item gathering would have added in the same //! situation. This detects mentioned items that have *not* been optimized away and hence don't //! need a dedicated traversal. enum CollectionMode { /// Collect items that are used, i.e., actually needed for codegen. /// /// Which items are used can depend on optimization levels, as MIR optimizations can remove /// uses. UsedItems, /// Collect items that are mentioned. The goal of this mode is that it is independent of /// optimizations: the set of "mentioned" items is computed before optimizations are run. /// /// The exact contents of this set are *not* a stable guarantee. (For instance, it is currently /// computed after drop-elaboration. If we ever do some optimizations even in debug builds, we /// might decide to run them before computing mentioned items.) The key property of this set is /// that it is optimization-independent. MentionedItems, } ``` And the `mentioned_items` MIR body field docs: ```rust /// Further items that were mentioned in this function and hence *may* become monomorphized, /// depending on optimizations. We use this to avoid optimization-dependent compile errors: the /// collector recursively traverses all "mentioned" items and evaluates all their /// `required_consts`. /// /// This is *not* soundness-critical and the contents of this list are *not* a stable guarantee. /// All that's relevant is that this set is optimization-level-independent, and that it includes /// everything that the collector would consider "used". (For example, we currently compute this /// set after drop elaboration, so some drop calls that can never be reached are not considered /// "mentioned".) See the documentation of `CollectionMode` in /// `compiler/rustc_monomorphize/src/collector.rs` for more context. pub mentioned_items: Vec<Spanned<MentionedItem<'tcx>>>, ``` Fixes rust-lang#107503

saethlin · 2024-03-20T15:21:39Z

Though I guess that means it has to run MIR opts on them, which is work we currently avoid doing. How likely is it that people have large amounts of monomorphic functions that never get mentioned (transitively) in anything "reachable"...?

FYI, #109247 broke a handful of crates for example #110475 because of invalid dead code. Errors in monomorphic dead code I'm not sure, but errors in dead code surely exist, and I find it concerning that when we uncover these errors they get reported as regressions. Perhaps people would be more accepting of such a change if we announce it beforehand and expand our detection of erroneous code only once.

RalfJung · 2024-03-20T15:51:04Z

Ah, good point. I was mostly worried about performance. I don't know if there are cases where code would previously build with with and without optimizations, and then after that change it now fails in both cases. But it's very possible.

I'm currently running this as a perf experiment in #122568, but I don't intend to land it in the same change. The rest of #122568 I am fairly sure only affects code that already fails when built without optimizations.

traviscross · 2024-03-20T20:44:18Z

@rustbot labels -I-lang-nominated

We discussed this in lang triage today. Our consensus was that this is a bug and the fix can go forward with no further action from lang.

Regarding whether this should block the stabilization of inline const, we tentatively felt that it should not, but we wanted to discuss that with more of the team before resolving the blocking concern on #104087.

RalfJung · 2024-03-20T20:59:09Z

Regarding whether this should block the stabilization of inline const, we tentatively felt that it should not, but we wanted to discuss that with more of the team before resolving the #104087 (comment) on #104087.

Ah, reading that concern now gives me flashbacks. ;)

That concern makes a difference between "Optimization-dependent errors" and "Errors in unused code". It turns out those cannot be disentangled, as basically all notions of "used" that exist in rustc depend on optimization levels. (This was not the case back when the comment was written, but is true ever since #[inline] is automatically inferred and that inference depends on optimization levels.)

saethlin · 2024-03-20T22:11:43Z

The only way I can imagine making cross_crate_inlinable not optimization-dependent is by analyzing unoptimized MIR and doing the analysis at all optimization levels. If we do that, I am confident that we will regress both our compile time and our code generation quality (we could of course delete it altogether to avoid regressing compile time). But such a change does nothing to fix the behavior of #[inline], which is the root (heh) cause here. I do not think that library authors would not be any more troubled by not getting errors due to cross_crate_inlinable than they would be by realizing that their inline-const assert that should have prevented shipping a bug did not do its job because they followed a clippy lint to put #[inline] on all their public items.

On the other hand, the fact that this bug has been shipping on nightly for quite some time and nobody has complained perhaps indicates that the impact is not too widespread.

I am very happy to see anyone trying to untangle the reachability/MIR collection code.

RalfJung · 2024-03-20T22:35:30Z

I do not think that library authors would not be any more troubled by not getting errors

That was three "not" in a row, you lost me here. ;)

I am very happy to see anyone trying to untangle the reachability/MIR collection code.

I gave up the hope of trying to simplify it, but maybe I can at least document it a bit better. ;)

saethlin · 2024-03-21T00:40:34Z

That was three "not" in a row, you lost me here. ;)

I think library authors will be equally confused by cross_crate_inlinable implications as they will be by plain old #[inline] possibly hiding errors.

(yeah wow that sentence is a mess)

RalfJung · 2024-03-21T06:53:11Z

I have opened #122814 for the collection root issue @tmiasko discovered.

workingjubilee · 2024-03-21T07:06:19Z

All uses in libraries I have seen are one of:

top-level items
only meant to stop you from monomorphizing code with the "wrong" type

and I have certainly seen a few particularly... dank... usages of these kinds of "const assertions".

RalfJung · 2024-03-21T07:11:22Z

To be clear, the only blessed pattern libs may use is that if a const is directly used inside some function, then whenever that function executes with a given choice of its generic parameters, the const succeeded evaluating. So we do not guarantee that the code in the OP will fail to build!

The point of this issue is that we don't want optimization-level-dependent behavior. But which functions we walk and evaluate consts for is still not a stable guarantee -- except that any function that actually gets executed has been walked and had its consts evaluated.

workingjubilee · 2024-03-21T07:21:34Z

yeah, that seems fine? weird but fine.

workingjubilee · 2024-03-21T07:26:02Z

the OP's code fails to build in both debug and release now. huh. weird.

RalfJung · 2024-03-21T08:22:05Z

Probably needs an inline(never). We have tests in tree that demo the opt dependent behavior; see the PR that closes this issue.

RalfJung · 2024-03-21T08:49:18Z

Hm, I wonder if inlining can also cause trouble here... if a call like f::<i32>() gets inlined, previously generic consts inside that body become monomorphic, and so if they ever get evaluated by later MIR passes then maybe that is evaluation that would not have happened otherwise (if this is all in a function that never gets collected)?

I'm beginning to wonder if MIR passes need a way to eval consts such that even if it fails, no error is emitted.

RalfJung · 2024-03-21T12:29:33Z

(After some experimentation with inlining) I think we aren't even computing optimized_mir for functions that do not participate in collection... in that case we're good. :)

recursively evaluate the constants in everything that is 'mentioned' This is another attempt at fixing rust-lang/rust#107503. The previous attempt at rust-lang/rust#112879 seems stuck in figuring out where the [perf regression](https://perf.rust-lang.org/compare.html?start=c55d1ee8d4e3162187214692229a63c2cc5e0f31&end=ec8de1ebe0d698b109beeaaac83e60f4ef8bb7d1&stat=instructions:u) comes from. In rust-lang/rust#122258 I learned some things, which informed the approach this PR is taking. Quoting from the new collector docs, which explain the high-level idea: ```rust //! One important role of collection is to evaluate all constants that are used by all the items //! which are being collected. Codegen can then rely on only encountering constants that evaluate //! successfully, and if a constant fails to evaluate, the collector has much better context to be //! able to show where this constant comes up. //! //! However, the exact set of "used" items (collected as described above), and therefore the exact //! set of used constants, can depend on optimizations. Optimizing away dead code may optimize away //! a function call that uses a failing constant, so an unoptimized build may fail where an //! optimized build succeeds. This is undesirable. //! //! To fix this, the collector has the concept of "mentioned" items. Some time during the MIR //! pipeline, before any optimization-level-dependent optimizations, we compute a list of all items //! that syntactically appear in the code. These are considered "mentioned", and even if they are in //! dead code and get optimized away (which makes them no longer "used"), they are still //! "mentioned". For every used item, the collector ensures that all mentioned items, recursively, //! do not use a failing constant. This is reflected via the [`CollectionMode`], which determines //! whether we are visiting a used item or merely a mentioned item. //! //! The collector and "mentioned items" gathering (which lives in `rustc_mir_transform::mentioned_items`) //! need to stay in sync in the following sense: //! //! - For every item that the collector gather that could eventually lead to build failure (most //! likely due to containing a constant that fails to evaluate), a corresponding mentioned item //! must be added. This should use the exact same strategy as the ecollector to make sure they are //! in sync. However, while the collector works on monomorphized types, mentioned items are //! collected on generic MIR -- so any time the collector checks for a particular type (such as //! `ty::FnDef`), we have to just onconditionally add this as a mentioned item. //! - In `visit_mentioned_item`, we then do with that mentioned item exactly what the collector //! would have done during regular MIR visiting. Basically you can think of the collector having //! two stages, a pre-monomorphization stage and a post-monomorphization stage (usually quite //! literally separated by a call to `self.monomorphize`); the pre-monomorphizationn stage is //! duplicated in mentioned items gathering and the post-monomorphization stage is duplicated in //! `visit_mentioned_item`. //! - Finally, as a performance optimization, the collector should fill `used_mentioned_item` during //! its MIR traversal with exactly what mentioned item gathering would have added in the same //! situation. This detects mentioned items that have *not* been optimized away and hence don't //! need a dedicated traversal. enum CollectionMode { /// Collect items that are used, i.e., actually needed for codegen. /// /// Which items are used can depend on optimization levels, as MIR optimizations can remove /// uses. UsedItems, /// Collect items that are mentioned. The goal of this mode is that it is independent of /// optimizations: the set of "mentioned" items is computed before optimizations are run. /// /// The exact contents of this set are *not* a stable guarantee. (For instance, it is currently /// computed after drop-elaboration. If we ever do some optimizations even in debug builds, we /// might decide to run them before computing mentioned items.) The key property of this set is /// that it is optimization-independent. MentionedItems, } ``` And the `mentioned_items` MIR body field docs: ```rust /// Further items that were mentioned in this function and hence *may* become monomorphized, /// depending on optimizations. We use this to avoid optimization-dependent compile errors: the /// collector recursively traverses all "mentioned" items and evaluates all their /// `required_consts`. /// /// This is *not* soundness-critical and the contents of this list are *not* a stable guarantee. /// All that's relevant is that this set is optimization-level-independent, and that it includes /// everything that the collector would consider "used". (For example, we currently compute this /// set after drop elaboration, so some drop calls that can never be reached are not considered /// "mentioned".) See the documentation of `CollectionMode` in /// `compiler/rustc_monomorphize/src/collector.rs` for more context. pub mentioned_items: Vec<Spanned<MentionedItem<'tcx>>>, ``` Fixes #107503

CAD97 added the C-bug Category: This is a bug. label Jan 31, 2023

rustbot added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Jan 31, 2023

joshtriplett mentioned this issue Jan 31, 2023

Stabilise inline_const #104087

Merged

CAD97 changed the title ~~Whether panicking in inline_const causes an error a depends on constant propagation~~ Whether panicking in inline_const causes an error a depends on optimization Jan 31, 2023

CAD97 changed the title ~~Whether panicking in inline_const causes an error a depends on optimization~~ Whether panicking in inline_const causes an error depends on optimization Jan 31, 2023

workingjubilee added the F-inline_const Inline constants (aka: const blocks, const expressions, anonymous constants) label Mar 5, 2023

RalfJung changed the title ~~Whether panicking in inline_const causes an error depends on optimization~~ Whether panicking in inline_const and assoc consts (and other post-mono errors) causes an error depends on optimization May 17, 2023

RalfJung mentioned this issue May 25, 2023

unused function is not monomorphized, so post-mono lints do not show up (in particular affects associated and inline consts) #106617

Closed

CAD97 mentioned this issue May 30, 2023

Are (non-free) generic constants guaranteed to be evaluated? #112090

Closed

RalfJung added A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) and removed F-inline_const Inline constants (aka: const blocks, const expressions, anonymous constants) labels May 31, 2023

This was referenced Mar 9, 2024

Report monomorphization time errors in dead code, too #112879

Closed

Draft: monomorphize things from dead code, too #122258

Closed

rust-lang deleted a comment Mar 20, 2024

rustbot removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Mar 20, 2024

RalfJung mentioned this issue Mar 21, 2024

Which functions are "reachable", and therefore subject to monomorphization-time checks, is optimization-dependent #122814

Open

bors closed this as completed in df8ac8f Mar 21, 2024

tmiasko mentioned this issue Mar 21, 2024

Evaluating constants in MIR optimizations introduces const eval errors #122828

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Const-eval errors in dead functions are optimization-dependent #107503

Const-eval errors in dead functions are optimization-dependent #107503

CAD97 commented Jan 31, 2023 •

edited

Loading

CAD97 commented Jan 31, 2023

joshtriplett commented Jan 31, 2023 •

edited

Loading

oskgo commented Jan 31, 2023

RalfJung commented Jan 31, 2023

CAD97 commented Jan 31, 2023

joshtriplett commented Jan 31, 2023

RalfJung commented Jan 31, 2023 •

edited

Loading

RalfJung commented Jan 31, 2023 •

edited

Loading

zirconium-n commented Feb 1, 2023 •

edited

Loading

RalfJung commented May 17, 2023 •

edited

Loading

traviscross commented May 23, 2023

RalfJung commented May 31, 2023

oli-obk commented May 31, 2023

tmiasko commented Mar 20, 2024 •

edited

Loading

RalfJung commented Mar 20, 2024 •

edited

Loading

RalfJung commented Mar 20, 2024 •

edited

Loading

tmiasko commented Mar 20, 2024

RalfJung commented Mar 20, 2024

RalfJung commented Mar 20, 2024

saethlin commented Mar 20, 2024

RalfJung commented Mar 20, 2024

traviscross commented Mar 20, 2024

RalfJung commented Mar 20, 2024

saethlin commented Mar 20, 2024

RalfJung commented Mar 20, 2024

saethlin commented Mar 21, 2024 •

edited

Loading

RalfJung commented Mar 21, 2024

workingjubilee commented Mar 21, 2024

RalfJung commented Mar 21, 2024

workingjubilee commented Mar 21, 2024

workingjubilee commented Mar 21, 2024

RalfJung commented Mar 21, 2024 via email

RalfJung commented Mar 21, 2024

RalfJung commented Mar 21, 2024

Const-eval errors in dead functions are optimization-dependent #107503

Const-eval errors in dead functions are optimization-dependent #107503

Comments

CAD97 commented Jan 31, 2023 • edited Loading

Meta

Related

CAD97 commented Jan 31, 2023

joshtriplett commented Jan 31, 2023 • edited Loading

oskgo commented Jan 31, 2023

RalfJung commented Jan 31, 2023

CAD97 commented Jan 31, 2023

joshtriplett commented Jan 31, 2023

RalfJung commented Jan 31, 2023 • edited Loading

RalfJung commented Jan 31, 2023 • edited Loading

zirconium-n commented Feb 1, 2023 • edited Loading

Footnotes

RalfJung commented May 17, 2023 • edited Loading

traviscross commented May 23, 2023

RalfJung commented May 31, 2023

oli-obk commented May 31, 2023

tmiasko commented Mar 20, 2024 • edited Loading

RalfJung commented Mar 20, 2024 • edited Loading

RalfJung commented Mar 20, 2024 • edited Loading

tmiasko commented Mar 20, 2024

RalfJung commented Mar 20, 2024

RalfJung commented Mar 20, 2024

saethlin commented Mar 20, 2024

RalfJung commented Mar 20, 2024

traviscross commented Mar 20, 2024

RalfJung commented Mar 20, 2024

saethlin commented Mar 20, 2024

RalfJung commented Mar 20, 2024

saethlin commented Mar 21, 2024 • edited Loading

RalfJung commented Mar 21, 2024

workingjubilee commented Mar 21, 2024

RalfJung commented Mar 21, 2024

workingjubilee commented Mar 21, 2024

workingjubilee commented Mar 21, 2024

RalfJung commented Mar 21, 2024 via email

RalfJung commented Mar 21, 2024

RalfJung commented Mar 21, 2024

CAD97 commented Jan 31, 2023 •

edited

Loading

joshtriplett commented Jan 31, 2023 •

edited

Loading

RalfJung commented Jan 31, 2023 •

edited

Loading

RalfJung commented Jan 31, 2023 •

edited

Loading

zirconium-n commented Feb 1, 2023 •

edited

Loading

RalfJung commented May 17, 2023 •

edited

Loading

tmiasko commented Mar 20, 2024 •

edited

Loading

RalfJung commented Mar 20, 2024 •

edited

Loading

RalfJung commented Mar 20, 2024 •

edited

Loading

saethlin commented Mar 21, 2024 •

edited

Loading