[NLL] Bad higher ranked subtype error #57374

matthewjasper · 2019-01-06T12:09:34Z

With the removal of the leak check the MIR type checker is now responsible for reporting higher-ranked lifetime errors in full NLL mode. The error messages are not currently very helpful, since they weren't user visible until now.

The following code (play):

#![feature(nll)]

fn main() {
    let x: fn(&'static ()) = |_| {};
    let y: for<'a> fn(&'a ()) = x;
}

gives the following output

error: higher-ranked subtype error
  --> <source>:19:12
   |
19 |     let x: fn(&'static ()) = |_| {};
   |            ^^^^^^^^^^^^^^^
error: aborting due to previous error
Compiler returned: 1

In migrate mode or with AST borrowck the error is much clearer:

error[E0308]: mismatched types
  --> <source>:20:33
   |
20 |     let y: for<'a> fn(&'a ()) = x;
   |                                 ^ one type is more general than the other
   |
   = note: expected type `for<'a> fn(&'a ())`
              found type `fn(&'static ())`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
Compiler returned: 1

cc @rust-lang/wg-compiler-nll

The text was updated successfully, but these errors were encountered:

nikomatsakis · 2019-01-07T15:15:59Z

Yeah, I intended to port the newer errors to NLL but didn't do it yet since they are hidden by migration mode. But clearly we need to do that before we can stabilize NLL further.

nikomatsakis · 2019-01-07T15:16:20Z

Nominating for discussion in the NLL meeting -- this should probably be prioritized.

nikomatsakis · 2019-01-09T20:41:00Z

Discussed in the NLL meeting. Assigning to @lqd but also to me to leave some mentoring notes and/or sync with @lqd

pnkfelix · 2019-01-25T13:23:22Z

somewhat related bug: #57362

pnkfelix · 2019-01-30T10:52:29Z

N.B.: This bug continues to persist even after Issue #57362 was resolved by PR #57901

lqd · 2019-02-27T20:03:24Z

With the temporary return of the leak-check from #58592, this issue has expectedly "un-regressed" to diagnostics levels very similar to pre-Universes or AST borrowck:

error[E0308]: mismatched types
 --> src/main.rs:5:33
  |
5 |     let y: for<'a> fn(&'a ()) = x;
  |                                 ^ expected concrete lifetime, found bound lifetime parameter 'a
  |
  = note: expected type `for<'a> fn(&'a ())`
             found type `fn(&'static ())`

pnkfelix · 2019-02-28T09:53:58Z

As discussed in the NLL meeting last night, one can use -Z no-leak-check to skip the leak check and thus return to the (regressed) behavior and thus attempt to fix it properly.

lqd · 2019-03-06T14:41:37Z

As mentioned on Zulip, I have made some progress here (and have rambling/meandering notes from the exploratory analysis), but will need some guidance to continue, so unassigning myself until then.

pnkfelix · 2019-03-28T13:55:33Z

triage: downgrading to P-medium.

Blocks: #59490

As described in rust-lang#57374, NLL currently produces unhelpful higher-ranked trait bound (HRTB) errors when '-Zno-leak-check' is enabled. This PR tackles one half of this issue - making the error message point at the proper span. The error message itself is still the very generic "higher-ranked subtype error", but this can be improved in a follow-up PR. The root cause of the bad spans lies in how NLL attempts to compute the 'blamed' region, for which it will retrieve a span for. Consider the following code, which (correctly) does not compile: ```rust let my_val: u8 = 25; let a: &u8 = &my_val; let b = a; let c = b; let d: &'static u8 = c; ``` This will cause NLL to generate the following subtype constraints: d :< c c :< b b <: a Since normal Rust lifetimes are covariant, this results in the following region constraints (I'm using 'd to denote the lifetime of 'd', 'c to denote the lifetime of 'c, etc.): 'c: 'd 'b: 'c 'a: 'b From this, we can derive that 'a: 'd holds, which implies that 'a: 'static must hold. However, this is not the case, since 'a refers to 'my_val', which does not outlive the current function. When NLL attempts to infer regions for this code, it will see that the region 'a has grown 'too large' - it will be inferred to outlive 'static, despite the fact that is not declared as outliving 'static We can find the region responsible, 'd, by starting at the *end* of the 'constraint chain' we generated above. This works because for normal (non-higher-ranked) lifetimes, we generally build up a 'chain' of lifetime constraints *away* from the original variable/lifetime. That is, our original lifetime 'a is required to outlive progressively more regions. If it ends up living for too long, we can look at the 'end' of this chain to determine the 'most recent' usage that caused the lifetime to grow too large. However, this logic does not work correctly when higher-ranked trait bounds (HRTBs) come into play. This is because HRTBs have *contravariance* with respect to their bound regions. For example, this code snippet compiles: ```rust let a: for<'a> fn(&'a ()) = |_| {}; let b: fn(&'static ()) = a; ``` Here, we require that 'a' is a subtype of 'b'. Because of contravariance, we end up with the region constraint 'static: 'a, *not* 'a: 'static This means that our 'constraint chains' grow in the opposite direction of 'normal lifetime' constraint chains. As we introduce subtypes, our lifetime ends up being outlived by other lifetimes, rather than outliving other lifetimes. Therefore, starting at the end of the 'constraint chain' will cause us to 'blame' a lifetime close to the original definition of a variable, instead of close to where the bad lifetime constraint is introduced. This PR improves how we select the region to blame for 'too large' universal lifetimes, when bound lifetimes are involved. If the region we're checking is a 'placeholder' region (e.g. the region 'a' in for<'a>, or the implicit region in fn(&())), we start traversing the constraint chain from the beginning, rather than the end. There are two (maybe more) different ways we generate region constraints for NLL: requirements generated from trait queries, and requirements generated from MIR subtype constraints. While the former always use explicit placeholder regions, the latter is more tricky. In order to implement contravariance for HRTBs, TypeRelating replaces placeholder regions with existential regions. This requires us to keep track of whether or not an existential region was originally a placeholder region. When we look for a region to blame, we check if our starting region is either a placeholder region or is an existential region created from a placeholder region. If so, we start iterating from the beginning of the constraint chain, rather than the end.

…akis Improve HRTB error span when -Zno-leak-check is used As described in rust-lang#57374, NLL currently produces unhelpful higher-ranked trait bound (HRTB) errors when '-Zno-leak-check' is enabled. This PR tackles one half of this issue - making the error message point at the proper span. The error message itself is still the very generic "higher-ranked subtype error", but this can be improved in a follow-up PR. The root cause of the bad spans lies in how NLL attempts to compute the 'blamed' region, for which it will retrieve a span for. Consider the following code, which (correctly) does not compile: ```rust let my_val: u8 = 25; let a: &u8 = &my_val; let b = a; let c = b; let d: &'static u8 = c; ``` This will cause NLL to generate the following subtype constraints: d :< c c :< b b <: a Since normal Rust lifetimes are covariant, this results in the following region constraints (I'm using 'd to denote the lifetime of 'd', 'c to denote the lifetime of 'c, etc.): 'c: 'd 'b: 'c 'a: 'b From this, we can derive that 'a: 'd holds, which implies that 'a: 'static must hold. However, this is not the case, since 'a refers to 'my_val', which does not outlive the current function. When NLL attempts to infer regions for this code, it will see that the region 'a has grown 'too large' - it will be inferred to outlive 'static, despite the fact that is not declared as outliving 'static We can find the region responsible, 'd, by starting at the *end* of the 'constraint chain' we generated above. This works because for normal (non-higher-ranked) lifetimes, we generally build up a 'chain' of lifetime constraints *away* from the original variable/lifetime. That is, our original lifetime 'a is required to outlive progressively more regions. If it ends up living for too long, we can look at the 'end' of this chain to determine the 'most recent' usage that caused the lifetime to grow too large. However, this logic does not work correctly when higher-ranked trait bounds (HRTBs) come into play. This is because HRTBs have *contravariance* with respect to their bound regions. For example, this code snippet compiles: ```rust let a: for<'a> fn(&'a ()) = |_| {}; let b: fn(&'static ()) = a; ``` Here, we require that 'a' is a subtype of 'b'. Because of contravariance, we end up with the region constraint 'static: 'a, *not* 'a: 'static This means that our 'constraint chains' grow in the opposite direction of 'normal lifetime' constraint chains. As we introduce subtypes, our lifetime ends up being outlived by other lifetimes, rather than outliving other lifetimes. Therefore, starting at the end of the 'constraint chain' will cause us to 'blame' a lifetime close to the original definition of a variable, instead of close to where the bad lifetime constraint is introduced. This PR improves how we select the region to blame for 'too large' universal lifetimes, when bound lifetimes are involved. If the region we're checking is a 'placeholder' region (e.g. the region 'a' in for<'a>, or the implicit region in fn(&())), we start traversing the constraint chain from the beginning, rather than the end. There are two (maybe more) different ways we generate region constraints for NLL: requirements generated from trait queries, and requirements generated from MIR subtype constraints. While the former always use explicit placeholder regions, the latter is more tricky. In order to implement contravariance for HRTBs, TypeRelating replaces placeholder regions with existential regions. This requires us to keep track of whether or not an existential region was originally a placeholder region. When we look for a region to blame, we check if our starting region is either a placeholder region or is an existential region created from a placeholder region. If so, we start iterating from the beginning of the constraint chain, rather than the end.

nnethercote · 2020-08-07T01:10:10Z

I hit this today working on the compiler, calling a function with this signature:

pub fn link_name<F>(check_name: F, attrs: &[ast::Attribute]) -> Option<Symbol>
where
    F: Fn(&ast::Attribute, Symbol) -> bool

I had no idea what "Bad higher ranked subtype error" meant, so I googled and found this issue, and concluded it was somehow related to lifetimes. After some experimentation I got this signature to work:

pub fn link_name<'a, F>(check_name: F, attrs: &'a [ast::Attribute]) -> Option<Symbol>
where
    F: Fn(&'a ast::Attribute, Symbol) -> bool

So it was a happy ending, but there was some wailing and gnashing of teeth along the way.

Aaron1011 · 2021-08-27T17:26:41Z

With #88270 merged, the only test cases that still cause a higher ranked subtype error all use unstable features / Polonious. Are there any remaining cases where we get that message with stable code?

lqd · 2021-08-28T16:55:25Z

None that I'm personally aware of.

Note that the TAIT test triggering the higher-ranked subtype error is really triggering it, whereas the polonius ones were likely fixed by the 2 previous PRs: these blessed expectations haven't been updated yet (and CI doesn't validate them as of yet).

This issue is probably the closest/only issue tracking this specific diagnostic, so we could still use it to track the rest of the work that they need, or close it and open new ones.

From #86700 you can see that there are at least a few remaining tasks:

matching non-NLL output in these error messages, as requested by @estebank here. This probably will require passing these obligations and causes around. Otherwise we won't be able to be as precise as the current output and it would regress the diagnostics too much. There are a number of these cases Esteban pointed out during review.
the parity to non-NLL is also needed in some of the names currently used in the HRTB errors, for example this uses synthetic names for the regions, whereas non-NLL output uses the names from user code. It's likely that fixing the point above and having the correct obligations would also fix this though.
(some clean-up of the implementation is also required, but that's more of a task for enabling full-NLLs rather than this issue's errors)

Aaron1011 · 2021-08-28T23:00:36Z

matching non-NLL output in these error messages, as requested by @estebank here. This probably will require passing these obligations and causes around. Otherwise we won't be able to be as precise as the current output and it would regress the diagnostics too much. There are a number of these cases Esteban pointed out during review.

I'll start working on that

In some cases, we emit borrowcheck diagnostics pointing at a particular field expression in a struct expression (e.g. `MyStruct { field: my_expr }`). However, this behavior currently relies on us choosing the `ConstraintCategory::Boring` with the 'correct' span. When adding additional variants to `ConstraintCategory`, (or changing existing usages away from `ConstraintCategory::Boring`), the current behavior can easily get broken, since a non-boring constraint will get chosen over a boring one. To make the diagnostic output less fragile, this commit adds a `ConstraintCategory::Usage` variant. We use this variant for the temporary assignments created for each field of an aggregate we are constructing. Using this new variant, we can emit a message mentioning "this usage", emphasizing the fact that the error message is related to the specific use site (in the struct expression). This is preparation for additional work on improving NLL error messages (see rust-lang#57374)

Add `ConstraintCategory::Usage` for handling aggregate construction In some cases, we emit borrowcheck diagnostics pointing at a particular field expression in a struct expression (e.g. `MyStruct { field: my_expr }`). However, this behavior currently relies on us choosing the `ConstraintCategory::Boring` with the 'correct' span. When adding additional variants to `ConstraintCategory`, (or changing existing usages away from `ConstraintCategory::Boring`), the current behavior can easily get broken, since a non-boring constraint will get chosen over a boring one. To make the diagnostic output less fragile, this commit adds a `ConstraintCategory::Usage` variant. We use this variant for the temporary assignments created for each field of an aggregate we are constructing. Using this new variant, we can emit a message mentioning "this usage", emphasizing the fact that the error message is related to the specific use site (in the struct expression). This is preparation for additional work on improving NLL error messages (see rust-lang#57374)

In some cases, we emit borrowcheck diagnostics pointing at a particular field expression in a struct expression (e.g. `MyStruct { field: my_expr }`). However, this behavior currently relies on us choosing the `ConstraintCategory::Boring` with the 'correct' span. When adding additional variants to `ConstraintCategory`, (or changing existing usages away from `ConstraintCategory::Boring`), the current behavior can easily get broken, since a non-boring constraint will get chosen over a boring one. To make the diagnostic output less fragile, this commit adds a `ConstraintCategory::Usage` variant. We use this variant for the temporary assignments created for each field of an aggregate we are constructing. Using this new variant, we can emit a message mentioning "this usage", emphasizing the fact that the error message is related to the specific use site (in the struct expression). This is preparation for additional work on improving NLL error messages (see rust-lang#57374)

Add `ConstraintCategory::Usage` for handling aggregate construction In some cases, we emit borrowcheck diagnostics pointing at a particular field expression in a struct expression (e.g. `MyStruct { field: my_expr }`). However, this behavior currently relies on us choosing the `ConstraintCategory::Boring` with the 'correct' span. When adding additional variants to `ConstraintCategory`, (or changing existing usages away from `ConstraintCategory::Boring`), the current behavior can easily get broken, since a non-boring constraint will get chosen over a boring one. To make the diagnostic output less fragile, this commit adds a `ConstraintCategory::Usage` variant. We use this variant for the temporary assignments created for each field of an aggregate we are constructing. Using this new variant, we can emit a message mentioning "this usage", emphasizing the fact that the error message is related to the specific use site (in the struct expression). This is preparation for additional work on improving NLL error messages (see rust-lang#57374)

Aaron1011 · 2021-09-25T16:42:38Z

I've opened #89249 to improve the cause information for some NLL error messages.

Aaron1011 · 2021-09-25T18:10:17Z

the parity to non-NLL is also needed in some of the names currently used in the HRTB errors, for example this uses synthetic names for the regions, whereas non-NLL output uses the names from user code. It's likely that fixing the point above and having the correct obligations would also fix this though.

I've opened #89250 to address this. It turned out to be caused by bound region anonimization during typeck.

Aaron1011 · 2021-09-30T19:52:51Z

Progress update:

From #86700 you can see that there are at least a few remaining tasks:

matching non-NLL output in these error messages, as requested by @estebank here. This probably will require passing these obligations and causes around. Otherwise we won't be able to be as precise as the current output and it would regress the diagnostics too much. There are a number of these cases Esteban pointed out during review.

PR #89249 has been merged, which makes NLL mode display the note that we display in non-NLL mode. I left comments on @estebank 's other requests in that PR - both of them are issues in non-NLL mode as well, so they're not directly related to this issue.

the parity to non-NLL is also needed in some of the names currently used in the HRTB errors, for example this uses synthetic names for the regions, whereas non-NLL output uses the names from user code. It's likely that fixing the point above and having the correct obligations would also fix this though.

This was addressed in PR #89250

(some clean-up of the implementation is also required, but that's more of a task for enabling full-NLLs rather than this issue's errors)

This still needs to be done, but it's not currently affecting the user-visible output

Aaron1011 · 2021-09-30T21:53:02Z

Are there any other user-visible diagnostic issues that need addressing?

lqd · 2021-10-01T19:18:42Z

On stable: I don't think so. It's also unlikely there are other open issues about them.

On nightly: like last time, some TAIT uses trigger the bad higher ranked subtype errors. Since Oli is currently revamping that, and it's unstable, there's no urgency to handle these IMO.

Aaron1011 · 2021-12-18T20:42:20Z

Issue #89620 hits a higher-ranked subtype error with #![feature(nll)]:

#![feature(nll)]

fn bar<Input>() -> impl Fn(Input) {
    |i| todo!()
}
    
fn foo() -> impl Fn(&str) {
    bar()
}

produces:

error: higher-ranked subtype error
 --> src/lib.rs:8:5
  |
8 |     bar()
  |     ^^^^^

error: could not compile `playground` due to previous error

Aaron1011 · 2021-12-27T18:23:02Z

I've opened #92306 to address the issue with stable uses of opaque types

marmeladema · 2022-03-31T22:38:38Z

The error message is now identical between stable and nightly with nll enabled:

error[E0308]: mismatched types
 --> src/main.rs:5:33
  |
5 |     let y: for<'a> fn(&'a ()) = x;
  |                                 ^ one type is more general than the other
  |
  = note: expected fn pointer `for<'a> fn(&'a ())`
             found fn pointer `fn(&())`

For more information about this error, try `rustc --explain E0308`.

Maybe this issue can now be closed?

estebank · 2022-03-31T22:43:44Z

The current output for aaron's case above

With nll

error: implementation of `Fn` is not general enough
 --> src/lib.rs:8:5
  |
8 |     bar()
  |     ^^^^^ implementation of `Fn` is not general enough
  |
  = note: `impl Fn(&'2 str)` must implement `Fn<(&'1 str,)>`, for any lifetime `'1`...
  = note: ...but it actually implements `Fn<(&'2 str,)>`, for some specific lifetime `'2`

error[E0308]: mismatched types
 --> src/lib.rs:8:5
  |
3 | fn bar<Input>() -> impl Fn(Input) {
  |                    --------------
  |                    |
  |                    the expected opaque type
  |                    the found opaque type
...
8 |     bar()
  |     ^^^^^ one type is more general than the other
  |
  = note: expected associated type `<impl Fn(&str) as FnOnce<(&str,)>>::Output`
             found associated type `<impl Fn(&str) as FnOnce<(&str,)>>::Output`

and without:

error: implementation of `Fn` is not general enough
 --> src/lib.rs:7:27
  |
7 |   fn foo() -> impl Fn(&str) {
  |  ___________________________^
8 | |     bar()
9 | | }
  | |_^ implementation of `Fn` is not general enough
  |
  = note: `impl Fn(&'2 str)` must implement `Fn<(&'1 str,)>`, for any lifetime `'1`...
  = note: ...but it actually implements `Fn<(&'2 str,)>`, for some specific lifetime `'2`

marmeladema · 2022-03-31T22:48:51Z

@estebank I am sorry, but it's not obvious to me which one is better?

Aaron1011 · 2022-04-20T20:02:52Z

I think the 'error: implementation of Fn is not general enough' message is better with NLL, since we point to the location responsible for producing the hidden type, instead of pointing at the entire function. However, the 'mismatched types' error is confusing and redundant.

jackh726 · 2022-05-21T16:49:46Z

Found a very similar higher-ranked lifetime error in https://github.com/rust-lang/rust/blob/master/src/test/ui/higher-rank-trait-bounds/issue-59311.nll.stderr

estebank · 2022-05-24T18:04:28Z

I think that

  = note: `impl Fn(&'2 str)` must implement `Fn<(&'1 str,)>`, for any lifetime `'1`...
  = note: ...but it actually implements `Fn<(&'2 str,)>`, for some specific lifetime `'2`

could be improved by making the output closer to code people can write

  = note: `impl Fn(&'2 str)` has a specific lifetime `'2`, but must work for `for<'1> Fn<(&'1 str,)>` instead

jackh726 · 2022-05-24T19:29:02Z

@estebank I think you're correct, but I think that might be better for a separate issue?

estebank · 2022-06-01T17:38:03Z

~~@jackh726 yes, a separate PR is always in the table for these kind of fixes :)~~

Sorry, a separate ticket... maybe. I do tend to group things in the same ticket or hijack an earlier one when it makes sense, which I feel it does here, but I'm not against more, smaller tickets.

jackh726 · 2022-06-01T19:42:19Z

Imo this isn't the right issue for that. I think this should be purely to remove any "bad higher ranked subtype"-like errors. As it stands, nearly all have been removed and match non-NLL behavior. A separate issue could be opened to improve that error in NLL (unlikely to be relevant for non-NLL, since it'll likely get stabilized soon).

matthewjasper added A-NLL Area: Non Lexical Lifetimes (NLL) NLL-diagnostics Working torwads the "diagnostic parity" goal labels Jan 6, 2019

nikomatsakis added I-nominated T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 7, 2019

nikomatsakis assigned lqd Jan 9, 2019

nikomatsakis added P-high High priority and removed I-nominated labels Jan 9, 2019

nikomatsakis self-assigned this Jan 9, 2019

pnkfelix self-assigned this Jan 17, 2019

pnkfelix mentioned this issue Jan 21, 2019

NLL: turn on borrowck=migrate by default on 2015 edition #57804

Closed

pnkfelix unassigned lqd Mar 6, 2019

pnkfelix added P-medium Medium priority and removed P-high High priority labels Mar 28, 2019

Aaron1011 mentioned this issue Aug 18, 2019

Improve HRTB error span when -Zno-leak-check is used #63678

Merged

Aaron1011 mentioned this issue Sep 6, 2021

Add ConstraintCategory::Usage for handling aggregate construction #88708

Merged

lqd mentioned this issue Oct 7, 2021

Nonsensical diagnostic when returning closure #89620

Open

QuineDot mentioned this issue Mar 20, 2022

Higher-ranked fn pointers can be cast but no longer coerce #95132

Closed

eddyb mentioned this issue Aug 19, 2022

Redundant error for "implementation ... not general enough" in "NLL" mode / since 1.63 (when it was made permanent). #100742

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[NLL] Bad higher ranked subtype error #57374

[NLL] Bad higher ranked subtype error #57374

matthewjasper commented Jan 6, 2019 •

edited by pnkfelix

Loading

nikomatsakis commented Jan 7, 2019

nikomatsakis commented Jan 7, 2019

nikomatsakis commented Jan 9, 2019

pnkfelix commented Jan 25, 2019

pnkfelix commented Jan 30, 2019

lqd commented Feb 27, 2019

pnkfelix commented Feb 28, 2019

lqd commented Mar 6, 2019 •

edited

Loading

pnkfelix commented Mar 28, 2019

nnethercote commented Aug 7, 2020

Aaron1011 commented Aug 27, 2021

lqd commented Aug 28, 2021 •

edited

Loading

Aaron1011 commented Aug 28, 2021

Aaron1011 commented Sep 25, 2021

Aaron1011 commented Sep 25, 2021

Aaron1011 commented Sep 30, 2021

Aaron1011 commented Sep 30, 2021

lqd commented Oct 1, 2021

Aaron1011 commented Dec 18, 2021

Aaron1011 commented Dec 27, 2021 •

edited

Loading

marmeladema commented Mar 31, 2022 •

edited

Loading

estebank commented Mar 31, 2022

marmeladema commented Mar 31, 2022

Aaron1011 commented Apr 20, 2022 •

edited

Loading

jackh726 commented May 21, 2022

estebank commented May 24, 2022 •

edited

Loading

jackh726 commented May 24, 2022

estebank commented Jun 1, 2022 •

edited

Loading

jackh726 commented Jun 1, 2022

[NLL] Bad higher ranked subtype error #57374

[NLL] Bad higher ranked subtype error #57374

Comments

matthewjasper commented Jan 6, 2019 • edited by pnkfelix Loading

nikomatsakis commented Jan 7, 2019

nikomatsakis commented Jan 7, 2019

nikomatsakis commented Jan 9, 2019

pnkfelix commented Jan 25, 2019

pnkfelix commented Jan 30, 2019

lqd commented Feb 27, 2019

pnkfelix commented Feb 28, 2019

lqd commented Mar 6, 2019 • edited Loading

pnkfelix commented Mar 28, 2019

nnethercote commented Aug 7, 2020

Aaron1011 commented Aug 27, 2021

lqd commented Aug 28, 2021 • edited Loading

Aaron1011 commented Aug 28, 2021

Aaron1011 commented Sep 25, 2021

Aaron1011 commented Sep 25, 2021

Aaron1011 commented Sep 30, 2021

Aaron1011 commented Sep 30, 2021

lqd commented Oct 1, 2021

Aaron1011 commented Dec 18, 2021

Aaron1011 commented Dec 27, 2021 • edited Loading

marmeladema commented Mar 31, 2022 • edited Loading

estebank commented Mar 31, 2022

marmeladema commented Mar 31, 2022

Aaron1011 commented Apr 20, 2022 • edited Loading

jackh726 commented May 21, 2022

estebank commented May 24, 2022 • edited Loading

jackh726 commented May 24, 2022

estebank commented Jun 1, 2022 • edited Loading

jackh726 commented Jun 1, 2022

matthewjasper commented Jan 6, 2019 •

edited by pnkfelix

Loading

lqd commented Mar 6, 2019 •

edited

Loading

lqd commented Aug 28, 2021 •

edited

Loading

Aaron1011 commented Dec 27, 2021 •

edited

Loading

marmeladema commented Mar 31, 2022 •

edited

Loading

Aaron1011 commented Apr 20, 2022 •

edited

Loading

estebank commented May 24, 2022 •

edited

Loading

estebank commented Jun 1, 2022 •

edited

Loading