Use the new `TypeUseLocation` default locations #165

wmdietl · 2024-02-08T17:03:04Z

Something still seems to be missing, failure in NullUnmarkedUndoesNullMarkedForWildcards.java is odd.

Co-authored-by: David P. Baker <dpb@google.com>

Co-authored-by: Chris Povirk <cpovirk@google.com>

to compare against NullUnmarked locations. Use hacky ParametricTypeVariableUse to mark parametric type variable use defaults.

wmdietl · 2024-02-26T21:19:48Z

tests/ConformanceTestOnSamples-report.txt

@@ -70,11 +70,11 @@ FAIL: CaptureConvertedUnspecToOther.java: no unexpected facts
 FAIL: CaptureConvertedUnspecToOtherUnionNull.java: no unexpected facts
 FAIL: CaptureConvertedUnspecToOtherUnspec.java: no unexpected facts
 PASS: CastOfCaptureOfNotNullMarkedUnboundedWildcardForObjectBoundedTypeParameter.java: no unexpected facts
-PASS: CastOfCaptureOfUnboundedWildcardForNotNullMarkedObjectBoundedTypeParameter.java: no unexpected facts
+FAIL: CastOfCaptureOfUnboundedWildcardForNotNullMarkedObjectBoundedTypeParameter.java: no unexpected facts


The unexpected error for this test case is:

build/conformanceTests/samples/CastOfCaptureOfUnboundedWildcardForNotNullMarkedObjectBoundedTypeParameter.java:26: error: [type.argument.type.incompatible] incompatible type argument for type parameter T of Supplier. void x(Supplier<?> supplier) { ^ found : capture#576 of ? extends Object* required: Object*

I think the defaults work correctly: the IMPLICIT_WILDCARD_UPPER_BOUND_NO_SUPER default is @Nullable, which gets combined with the declared upper bound, resulting in capture of ? extends Object*.

However, that is not a subtype of Object*. @cpovirk does this look like some problem with the type hierarchy?

It is correct for the checker to produce an error here. The reason that it's showing up as FAIL is that the conformance-test framework doesn't support jspecify_nullness_not_enough_information yet, only jspecify_nullness_mismatch.

(Object* is not a subtype of Object* so as to indicate that, if you don't know what you have and you don't know what you need, we can't prove that it's safe. Our expectation is that few checkers (if any) will produce even a warning in this case—or even in a more-likely-to-be-unsafe case in which you have an Object? and need an Object*. Still, the tests label such cases accordingly. This labeling may help tools like the Checker Framework that make specific assumptions about unannotated code: If a line is labeled with jspecify_nullness_mismatch, a tool like the Checker Framework can consider itself to "pass" whether it produces an error there or not. This is in contrast to cases in which it should always produce an error and cases in which it never should.)

Thanks, so I did remember correctly that that is how unspecified nullness is supposed to work.

I've opened jspecify/jspecify#487 to add the optional error.

(In your penultimate sentence: If a line is labeled with jspecify_nullness_mismatch, a tool like the Checker Framework can consider itself to "pass" whether it produces an error there or not. Here you meant jspecify_nullness_not_enough_information, right?)

Oops, yes, sorry.

The error here (which we add as expected in jspecify/jspecify#487) feels wrong to me.
The captured wildcard is for that type parameter of Supplier. So while in general, two unspecified nullness can't be subtypes, here, the type argument is a capture of that unspecified nullness, so it will always match.
Even more fundamentally, when checking Supplier<?> the wildcard isn't captured at all - a capture only happens at a call/field access. So the found type is not what it should be.
What do you think?

I am still not sure where the code that makes the main branch avoid this error is :\

I thought maybe 89d9b72#diff-ce82a59b06d0d82bfc6d06835d1b06ac15619bc3a71617d32189d041f02ca9c0R270, but then I found that I'd removed that cocde in 8ba39b0

I thought maybe jspecify/checker-framework@00cc056, but then I found that I'd removed that code in jspecify/checker-framework@72c5c16.

Maybe 9348e76#diff-ce82a59b06d0d82bfc6d06835d1b06ac15619bc3a71617d32189d041f02ca9c0R894 is somehow related?

I also have open 74f564f, 7e662e3, and 824113a, but I'm not convinced that any of that is relevant.

OK, I started just diffing checker-framework against upstream, and the code jumped right out to me. At least, I assume this is the right code:

https://github.com/jspecify/checker-framework/blob/b84882d9b2f77c99081118cc7ad095dfcc3484f5/framework/src/main/java/org/checkerframework/common/basetype/BaseTypeValidator.java#L562

(That code was a small part of the large merge commit jspecify/checker-framework@2e588e7.)

Thanks a lot for tracking this down!
I'll look into fixing this in the reference checker or the framework.
Besides the error here, these incorrect captures are also the cause for #164.

Ah, do you think that it's possible that #164 is related to https://github.com/jspecify/checker-framework/blob/b84882d9b2f77c99081118cc7ad095dfcc3484f5/framework/src/main/java/org/checkerframework/framework/type/AnnotatedTypeFactory.java#L5017 (jspecify/checker-framework#47)?

That is, could there be two issues here?

The upstream checker performs a check that the wildcard bound (or capture thereof?) is in bounds (of the type-parameter bound? of the wildcard bound?). That leads to failures for JSpecify because Object* is not a subtype of Object*. My "fix" for that was to remove the possibly unnecessary check entirely. (cause of Capture of Object* is not compatible with Object*. jspecify#487)?)

When we do perform capture conversion, we get it wrong. (cause of main-eisop: x(Foo<? super T>) cannot override identical signature #164?)

The reason that it seems strange for #164 to be related to this issue is that #164 doesn't involve unspecified nullness.

But I guess that, if the tests of #164 start passing with this change, then it's a fix :) Still, maybe it's more that we're hiding the failure (by no longer checking the incorrect capture against anything) than fixing it (by making the results of capture correct)? I don't know :\

I should also write up something about type parameters in general that I've been thinking about recently. It might end up saving us some work... maybe....

9ee2796 uses hasEffectiveAnnotation instead of hasAnnotation. #164 has ? super T and when the code asked whether the wildcard had a particular annotation in the lower bound, it got "none", because the type variable T isn't annotated. hasEffectiveAnnotation follows bounds to find the first declared type.

I replaced all hasAnnotation with hasEffectiveAnnotation in the NullSpecAnnotatedTypeFactory. I should probably have that done more incrementally, as two more conformance tests fail now... let me see why that is. I should also look at uses of hasAnnotation in other files.

wmdietl · 2024-02-26T21:20:54Z

tests/minimal/UnboundedDefaultsToNonNull.java

@@ -0,0 +1,12 @@
+// Test case for Issue 161:


I've added this test case to show that the issue #161 is fixed.
I didn't find a file with this name in the samples.
@cpovirk Should I keep this file here or add it somewhere else?

Maybe it can live under conformance-tests/src/assertions? netdpb@ will be back Thursday :)

wmdietl · 2024-02-26T21:23:08Z

src/main/java/com/google/jspecify/nullness/NullSpecAnnotatedTypeFactory.java

+            Nullable.class,
+            NullnessUnspecified.class,
+            MinusNull.class,
+            ParametricTypeVariableUse.class));


I'll refactor how I do this in EISOP separately and add an explicit qualifier here. This is just a first hack.

…hecker into issue-161

wmdietl · 2024-02-27T02:46:21Z

A bit frustratingly, this doesn't fix #163 and #164. At least #163 I had hoped should be fixed by the change to TYPE_VARIABLE_USE defaults. I'll look some more.

wmdietl · 2024-03-22T20:16:58Z

Thanks for tracking this down, @cpovirk !
I'll look into why javac errors aren't surfaced properly and into fixing the problem introduced in jspecify/jspecify#485.

wmdietl · 2024-03-23T14:31:50Z

I opened jspecify/jspecify#498 to fix the compilation error. While doing that I ran into google/error-prone#4343. I ended up disabling error-prone on samples anyways, b/c there are too many warnings for the hand-crafted samples.

With that fixed, the numbers in this PR look much better. I'll still try to first track down why javac errors don't show up in test output - they do show up in stock EISOP.

wmdietl

There is some mismatch in running the conformance tests between my local setup and CI... not sure what's going on.
Once that is done, I suggest we finally merge this. Conformance test scores improve and #159, #161, and #163 are fixed.
Some of the sample tests produce slightly worse results, but I rather look at those separately.
@cpovirk Could you have a look at this PR and let me know what you think?

wmdietl · 2024-03-26T16:03:05Z

The mismatch is

        -PASS: implementWithNullableTypeArgument/implementwithnullabletypeargument/User.java: no unexpected facts
        +FAIL: implementWithNullableTypeArgument/implementwithnullabletypeargument/User.java: no unexpected facts

I'm trying to find what is different in CI.

src/main/java/com/google/jspecify/nullness/NullSpecAnnotatedTypeFactory.java

cpovirk · 2024-03-26T17:52:27Z

src/main/java/com/google/jspecify/nullness/NullSpecAnnotatedTypeFactory.java

@@ -861,8 +894,8 @@ protected AnnotatedTypeMirror substituteTypeVariable(
        substitute.replaceAnnotation(minusNull);
      } else if (argument.hasAnnotation(unionNull) || use.hasAnnotation(unionNull)) {
        substitute.replaceAnnotation(unionNull);
-      } else if (argument.hasAnnotation(nullnessOperatorUnspecified)
-          || use.hasAnnotation(nullnessOperatorUnspecified)) {
+      } else if (argument.hasEffectiveAnnotation(nullnessOperatorUnspecified)


I'm going to just not think about this part for now, given the chance that our substitution behavior will change in one or more ways (jspecify/jspecify#248 (comment), jspecify/jspecify#91 (comment)) and given my lack of deep understanding of the Checker Framework model :)

cpovirk · 2024-03-26T21:48:30Z

I kicked off an internal build with the current code in this PR (752ad09). I'll have to sort through the result in more detail on another day, but the main thing that jumps out to me at the moment is a lot of messages along the lines of found: Foo<T> | required: Foo<T>. It's somewhat like #164 but not resricted to ? super:

java/com/google/common/collect/HashBiMap.java:707: error: [override.param.invalid] Incompatible parameter type for entry.
        Entry<V, K> output(BiEntry<K, V> entry) {
                                         ^
  found   : BiEntry<K, V>
  required: BiEntry<K, V>
  Consequence: method in 
    Entry<V, K> output(BiEntry<K, V>)
  cannot override method in Itr<Entry<V, K>>
    Entry<V, K> output(BiEntry<K, V>)

wmdietl · 2024-03-28T14:28:44Z

I kicked off an internal build with the current code in this PR (752ad09). I'll have to sort through the result in more detail on another day, but the main thing that jumps out to me at the moment is a lot of messages along the lines of found: Foo<T> | required: Foo<T>. It's somewhat like #164 but not resricted to ? super:

Thanks for re-running your tests!
I think what is happening is that the @NullMarked is ignored when code comes from an Element, that is, a different compilation unit or bytecode.
We treat @NullMarked and @NullUnmarked as changes to defaults. Defaults are however only applied when we check source code. In stock CF, we write the defaulted types back into the Element, which then allows us to directly see the annotations in bytecode.
The reference checker intentionally does not store defaults back into bytecode. I think we need to change how we load bytecode and similarly look for @Null(Un)Marked on enclosing elements.
Similarly, when looking at stub files, stock CF only looks at @AnnotatedFor. I'm not sure the defaults set by @Null(Un)Marked have any effect in stubs and the annotated JDK.
Does either of these sound like you had work-arounds for them before?
I don't see how this PR would have made that behavior different, so I think we can still merge this.

Because the @NullMarked is ignored, the upper bounds for these type variables are UnknownNullness and therefore the override check fails. But fixing the override check, ala #164, is probably not enough and we need to fix the above handling of defaults.
(The error message is pretty cryptic, as it's the same type twice. The reference checker intentionally doesn't show bounds of type variables. I believe that in the bound we would see unknown nullness. Then we would still see the same type twice, but at least if one remembers that subtyping for unknown nullness is not reflexive, it might make sense.)

However, I'm still trying to figure out why the conformance test is different on CI than on my local machine...

cpovirk

Good info, thanks.

I'm still somewhat confused about the errors: If the problem were merely that we're seeing accidentally unspecified types, then I'd expect not to see errors, since we're running in lenient mode inside Google. But it's possible that we're seeing accidentally unspecified types and that we're not handling subtyping (and/or "same-type" checking?) correctly in the presence of unspecified types: As you say, we already have seen a similar-looking problem in #164.

As for workarounds: We certainly do have our own separate defaulting system. There seem to have been multiple reasons that led me down that path. I don't specifically remember being aware of the problem that you mentioned, but it's been a long time, so maybe I've just forgotten. (I could dig into the commit history, but it's probably academic.)

The rule of "look for defaults only in source code" probably also explains why I had to hack up the stub-file code so badly in order to recognize @NullMarked in the JDK stubs. Fortunately, I think we can get away without worrying about stub files for now. But it is good to have a deeper understanding of why that was hard to get working.

I'm fine with merging to lock in the progress so far.

cpovirk · 2024-04-01T15:52:09Z

Some notes:

Itr comes from the same compilation unit as the subclass: Both are in HashBiMap.java. So I don't think that a difference in defaulting between source files and class files explains it.
I'm also still unclear on "Defaults are however only applied when we check source code." I traced to https://github.com/eisop/checker-framework/blob/ddb3e090073311d88a0a2300ab5b4da8bed124c5/framework/src/main/java/org/checkerframework/framework/util/defaults/QualifierDefaults.java#L425-L461 and then to https://github.com/eisop/checker-framework/blob/ddb3e090073311d88a0a2300ab5b4da8bed124c5/framework/src/main/java/org/checkerframework/framework/util/defaults/QualifierDefaults.java#L745 (noting that getDeclAnnotation says it supports aliases), and that seems to support the idea that we could read defaults from class files (not source-retention @DefaultQualifier itself but at least class/runtime-retention aliases like @NullMarked). And when I added println debugging to defaultsAtDirect(Element elt) , I saw it called for types like java.lang.Object. (That doesn't mean that it works :) I didn't investigate further. But the checker does seem to be trying.) If I'm right about my first bullet, then this is academic for now, but it might matter for later.
Here's a minimized version:

import org.jspecify.annotations.NullMarked;
import org.jspecify.annotations.Nullable;

@NullMarked
class HashBiMapAlike<E extends @Nullable Object> {
  abstract class Super {
    abstract void accept(Entry<E> entry);
  }

  abstract class Sub extends Super {
    @Override
    abstract void accept(Entry<E> entry);
  }
}

interface Entry<E extends @Nullable Object> {}

$ ./demo HashBiMapAlike.java 
HashBiMapAlike.java:12: error: [override.param.invalid] Incompatible parameter type for entry.
    abstract void accept(Entry<E> entry);
                                  ^
  found   : Entry<E>
  required: Entry<E>
  Consequence: method in Sub
    void accept(Entry<E>)
  cannot override method in Super
    void accept(Entry<E>)
1 error

I confirmed that the above test passes at main-eisop (using my instructions from Use the new TypeUseLocation default locations #165 (comment)), but that still leaves the question of what sort of changes to defaulting or @ParametricNull might be the cause.

cpovirk · 2024-04-02T17:36:22Z

tl;dr I think the conformance-test runner needs to sort the input files. Not that that should matter, but I've seen it matter for my original samples integration, which I have set up to sort files.

Details:

I mentioned this part on an internal doc, but I'll say it here, too: The tests pass for me locally, as well. (That includes if I use JDK17 and if I use the ./gradlew build conformanceTests demoTest --include-build ../jspecify command line from CI.)

I wonder if we're seeing something similar to #165 (comment), in which an error from javac itself stops us from checking many files. And maybe our different systems have very slight difference in how javac behaves, either because of different versions or because of environmental perturbations, perhaps the most likely of which would be filesystem iteration order?? Even if we're not seeing a javac error, I have seen cases (unfortunately) in which the order of files matters.

To test that, I just tried a run in which the conformance tests use ImmutableSortedSet instead of ImmutableList for their input files. And... that produced the failure locally!

    diff (-expected +actual):
        @@ -1,4 +1,4 @@
        -# 73 pass; 500 fail; 573 total; 12.7% score
        +# 72 pass; 501 fail; 573 total; 12.6% score
         FAIL: AnnotatedInnerOfNonParameterized.java: no unexpected facts
         FAIL: AnnotatedInnerOfParameterized.java: no unexpected facts
         FAIL: AnnotatedReceiver.java: no unexpected facts
        @@ -532,7 +532,7 @@
         FAIL: ignoreAnnotations/ignoreannotations/IgnoreAnnotations.java: no unexpected facts
         PASS: implementWithNullableTypeArgument/implementwithnullabletypeargument/MyFunction.java: no unexpected facts
         PASS: implementWithNullableTypeArgument/implementwithnullabletypeargument/SuperFunction.java: no unexpected facts
        -PASS: implementWithNullableTypeArgument/implementwithnullabletypeargument/User.java: no unexpected facts
        +FAIL: implementWithNullableTypeArgument/implementwithnullabletypeargument/User.java: no unexpected facts
         PASS: memberSelectNonExpression/memberselectnonexpression/MemberSelectNonExpressions.java: no unexpected facts
         PASS: nonPlatformTypeParameter/nonplatformtypeparameter/NonPlatformTypeParameter.java: no unexpected facts
         PASS: nullnessUnspecifiedTypeParameter/nullnessunspecifiedtypeparameter/NullnessUnspecifiedTypeParameter.java:35:jspecify_nullness_mismatch

The extra error, incidentally, appears to be this:

OOPS: implementWithNullableTypeArgument/implementwithnullabletypeargument/User.java:25:test:cannot-convert:SuperFunction!<Object!, Object!> to Object apply(Object)!

2024-03-28T14:07:45.7406117Z       /home/runner/work/jspecify-reference-checker/jspecify-reference-checker/jspecify-reference-checker/build/conformanceTests/samples/implementWithNullableTypeArgument/implementwithnullabletypeargument/User.java:25: (override.return.invalid) Incompatible return type.
2024-03-28T14:07:45.7409196Z         @Nullable Object apply(@Nullable Object f);
2024-03-28T14:07:45.7409908Z                   ^
2024-03-28T14:07:45.7410397Z       found   : Object?
2024-03-28T14:07:45.7410929Z       required: Object

That looks like a substitution problem. (Sorry, I can't seem to remember whether your existing suspicion had been a substitution problem or not.)

Since there are multiple files involved in that sample, the ordering hypothesis is relatively plausible. And sure enough:

$ ./demo ../jspecify/samples/implementWithNullableTypeArgument/implementwithnullabletypeargument/SuperFunction.java ../jspecify/samples/implementWithNullableTypeArgument/implementwithnullabletypeargument/User.java ../jspecify/samples/implementWithNullableTypeArgument/implementwithnullabletypeargument/MyFunction.java 

(no errors)

$ ./demo ../jspecify/samples/implementWithNullableTypeArgument/implementwithnullabletypeargument/MyFunction.java ../jspecify/samples/implementWithNullableTypeArgument/implementwithnullabletypeargument/SuperFunction.java ../jspecify/samples/implementWithNullableTypeArgument/implementwithnullabletypeargument/User.java 
../jspecify/samples/implementWithNullableTypeArgument/implementwithnullabletypeargument/User.java:25: error: [override.return.invalid] Incompatible return type.
    @Nullable Object apply(@Nullable Object f);
              ^
  found   : Object?
  required: Object
  Consequence: method in NullableObjectFunction
    Object? apply(Object?)
  cannot override method in SuperFunction<Object, Object>
    Object apply(Object)
1 error

While the order of the input files _shouldn't_ affect behavior, it sometimes does. Let's use a consistent order so that we at least don't see behavior differences between local and CI runs: #165 (comment)

…hecker into issue-161

wmdietl · 2024-04-10T01:00:55Z

tests/minimal/Issue159.java

@@ -0,0 +1,26 @@
+// Copyright 2024 The JSpecify Authors


@cpovirk @netdpb Let's re-start the discussion from #165 (comment)

I've added tests for the three fixed issues and the override test from one of the last comments. I could either remove them before we merge this or maybe move them from minimal to issues or some other sub-directory?

We can then merge this and I'll work on #164 in a new PR.

We discussed this today and settled on moving the tests. Done in 2588340
A future cleanup can move some of them to conformance tests and keep others.

wmdietl and others added 10 commits February 6, 2024 17:07

Use EISOP CF sources (#118)

33817d8

Co-authored-by: David P. Baker <dpb@google.com>

Document that detail messages should not be filtered out (#146)

324d817

Update tests/ConformanceTest-report.txt (#157)

1ef0817

Use standard error format (#154)

e673ee8

Handle both https and git@ clones (#158)

209435e

Co-authored-by: Chris Povirk <cpovirk@google.com>

Use the new TypeInformationPresenter to output more type information (

d9e96d0

#134)

Use the new TypeUseLocation.IMPLICIT_WILDCARD_UPPER_BOUND

1362fa2

Split out fields for NullMarked default locations, to make it easier

4a8bd5b

to compare against NullUnmarked locations. Use hacky ParametricTypeVariableUse to mark parametric type variable use defaults.

Add test for issue #161

cb1c7b2

Check out related eisop branch

cbebcf2

wmdietl changed the title ~~Use the new TypeUseLocation.IMPLICIT_WILDCARD_UPPER_BOUND~~ Use the new TypeUseLocation default locations Feb 26, 2024

Remove debugging output

a1a45fc

wmdietl commented Feb 26, 2024

View reviewed changes

This was referenced Feb 26, 2024

Change from ? super Object to ? super Number to avoid errors jspecify/jspecify#485

Merged

Capture of Object* is not compatible with Object*. jspecify/jspecify#487

Closed

wmdietl added 3 commits February 26, 2024 21:14

Map type.invalid.super.wildcard as an expected error (#166)

8eb4ab8

Merge branch 'main-eisop' of github.com:jspecify/jspecify-reference-c…

fad09d5

…hecker into issue-161

Remove special handling of type variables. Fixes #159.

04b8d84

This was referenced Feb 27, 2024

main-eisop crash in TernaryUnspecVsNoQualifier #159

Closed

Low-priority main-eisop: [type.invalid.super.wildcard] bounds must have the same annotations. #162

Open

wmdietl added 5 commits February 27, 2024 18:06

Use hasEffectiveAnnotation to handle TVs in bounds. Fixes #164.

9ee2796

Use dedicated ParametricNull qualifier

93b50dc

CF branch was merged

cf2aa1d

Specify hierarchy

859669f

Use hasAnnotation with unionNull, pending further investigation

f73dfbf

wmdietl marked this pull request as ready for review February 28, 2024 19:12

This was linked to issues Feb 28, 2024

main-eisop crash in TernaryUnspecVsNoQualifier #159

Closed

main-eisop: Unbounded wildcards default to non-nullable #161

Closed

main-eisop: x(Foo<? super T>) cannot override identical signature #164

Closed

wmdietl added 2 commits March 26, 2024 11:44

Undo some has[Effective]Annotation changes

77dc086

Rerun conformance tests

752ad09

wmdietl commented Mar 26, 2024

View reviewed changes

cpovirk approved these changes Mar 26, 2024

View reviewed changes

Output details in conformance tests

88d9c88

cpovirk approved these changes Mar 28, 2024

View reviewed changes

cpovirk mentioned this pull request Apr 2, 2024

Sort input files in the test runner. #168

Merged

cpovirk mentioned this pull request Apr 9, 2024

main-eisop NPE: Cannot invoke "com.sun.source.tree.Tree.getKind()" because "tree" is null #160

Closed

Re-instate work-around to type variable bound issue

a4d344b

wmdietl force-pushed the main-eisop branch from 8eb4ab8 to 11a2980 Compare April 10, 2024 00:35

wmdietl added 4 commits April 9, 2024 20:41

Merge branch 'main-eisop' of github.com:jspecify/jspecify-reference-c…

acf4230

…hecker into issue-161

Add tests for #159, #161, and #163.

5c25a46

Ensure tests are properly formatted

ac7487f

Add test of overrides.

9ba1aa8

wmdietl removed a link to an issue Apr 10, 2024

main-eisop: x(Foo<? super T>) cannot override identical signature #164

Closed

wmdietl commented Apr 10, 2024

View reviewed changes

Move regression tests to tests/regression.

2588340

wmdietl merged commit 76b33c9 into main-eisop Apr 11, 2024
3 of 5 checks passed

wmdietl deleted the issue-161 branch April 11, 2024 21:38

This was referenced Apr 11, 2024

main-eisop: Unbounded wildcards default to non-nullable #161

Closed

main-eisop: When class Foo<T> is null-unmarked, usages of T should have unspecified nullness #163

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use the new `TypeUseLocation` default locations #165

Use the new `TypeUseLocation` default locations #165

wmdietl commented Feb 8, 2024 •

edited

wmdietl Feb 26, 2024

cpovirk Feb 26, 2024

wmdietl Feb 26, 2024

cpovirk Feb 26, 2024

wmdietl Feb 27, 2024

cpovirk Feb 27, 2024

cpovirk Feb 27, 2024

wmdietl Feb 27, 2024

cpovirk Feb 27, 2024

wmdietl Feb 27, 2024

wmdietl Feb 26, 2024

cpovirk Feb 26, 2024

wmdietl Feb 26, 2024

wmdietl commented Feb 27, 2024

wmdietl commented Mar 22, 2024

wmdietl commented Mar 23, 2024

wmdietl left a comment

wmdietl commented Mar 26, 2024

cpovirk Mar 26, 2024

cpovirk commented Mar 26, 2024

wmdietl commented Mar 28, 2024

cpovirk left a comment

cpovirk commented Apr 1, 2024

cpovirk commented Apr 2, 2024

wmdietl Apr 10, 2024

wmdietl Apr 11, 2024

Use the new TypeUseLocation default locations #165

Use the new TypeUseLocation default locations #165

Conversation

wmdietl commented Feb 8, 2024 • edited

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

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

wmdietl commented Feb 27, 2024

wmdietl commented Mar 22, 2024

wmdietl commented Mar 23, 2024

wmdietl left a comment

Choose a reason for hiding this comment

wmdietl commented Mar 26, 2024

Choose a reason for hiding this comment

cpovirk commented Mar 26, 2024

wmdietl commented Mar 28, 2024

cpovirk left a comment

Choose a reason for hiding this comment

cpovirk commented Apr 1, 2024

cpovirk commented Apr 2, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Use the new `TypeUseLocation` default locations #165

Use the new `TypeUseLocation` default locations #165

wmdietl commented Feb 8, 2024 •

edited