Extensions: check for collisions #79702

jcouv · 2025-07-31T16:27:58Z

Overview:
For extension blocks, we produce grouping and marker type names. They have content-based hashes.
There are two kinds of possible collisions:

Those (non-cryptographic) hashes theoretically could suffer some collisions.
They also have known collisions due to information that is intentionally left out (such as the assembly identity where the types originate).

This PR implements a symbol-level check that ensures that we only allow extension blocks with identical IL-level signatures into a grouping type, and those with identical C#-level signatures into a marker type.
It is useful to look at ComputeExtensionGroupingRawName() and ComputeExtensionMarkerRawName() to see what information counts in IL-level vs. C#-level signature.

The only quirk (by design, but keeps surprising me) is that we decided that refkind doesn't count as part of IL-level signature.

Addresses one of the metadata follow-ups in #78963
Relates to test plan #76130

jcouv · 2025-08-01T03:00:13Z

src/Compilers/CSharp/Portable/Symbols/Source/ExtensionGroupingInfo.cs


+        /// <summary>
+        /// Reports a diagnostic when two extension blocks grouped into a single marker type have different C#-level signatures.
+        /// Note: It's fine for two extension blocks with different IL-level signatures to be grouped into the same grouping type, so we don't check for collisions there.


~~📝 This is illustrated by Grouping_30~~ #Closed

AlekseyTs · 2025-08-02T02:24:48Z

        hash = Hash.Combine(GetHashCodeForNamedArguments(attr.NamedArguments), hash);

Are we certain this step doesn't need to pay attention to _considerNamedArgumentsOrder? #Closed

Refers to: src/Compilers/Core/Portable/Symbols/Attributes/CommonAttributeDataComparer.cs:52 in 7f543e0. [](commit_id = 7f543e0, deletion_comment = False)

AlekseyTs · 2025-08-02T02:27:19Z

src/Compilers/Core/Portable/Symbols/Attributes/CommonAttributeDataComparer.cs

                attr1.IsConditionallyOmitted == attr2.IsConditionallyOmitted &&
                attr1.CommonConstructorArguments.SequenceEqual(attr2.CommonConstructorArguments) &&
-                attr1.NamedArguments.SequenceEqual(attr2.NamedArguments);
+                (_considerNamedArgumentsOrder ? attr1.NamedArguments.SequenceEqual(attr2.NamedArguments) : attr1.NamedArguments.SetEquals(attr2.NamedArguments));


attr1.NamedArguments

How are typeof values going to be compared? #Closed

They were compared with Default/AllNullableIgnoreOptions. I updated this to use AllIgnore and showed the impact on assembly attributes with tuples in a test.
I considered filing an issue for the order of comparison. It seems strange that we would be order-dependent for this. But I don't think we'd get to fixing this (low-pri)

AlekseyTs · 2025-08-02T02:29:01Z

src/Compilers/CSharp/Portable/CSharpResources.resx

    <value>Interpolated string handler arguments are not allowed in this context.</value>
  </data>
+  <data name="ERR_ExtensionBlockCollision" xml:space="preserve">
+    <value>This extension block collides with another extension block. They have different signatures, but result in the same marker type identifier.</value>


marker type

I think the reference to "marker type" is going to be confusing, it is not part of the language #Closed

AlekseyTs · 2025-08-02T02:30:30Z

src/Compilers/CSharp/Portable/CSharpResources.resx

    <value>Interpolated string handler arguments are not allowed in this context.</value>
  </data>
+  <data name="ERR_ExtensionBlockCollision" xml:space="preserve">
+    <value>This extension block collides with another extension block. They have different signatures, but result in the same marker type identifier.</value>


different signatures

Is there such a concept as an extension signature in the language? #Closed

AlekseyTs · 2025-08-02T02:35:20Z

src/Compilers/CSharp/Portable/Symbols/MemberSignatureComparer.cs

+                    ImmutableArray<TypeParameterSymbol> typeParams1 = member1.GetMemberTypeParameters();
+                    ImmutableArray<TypeParameterSymbol> typeParams2 = member2.GetMemberTypeParameters();
+
+                    if (_considerParameterNames && typeParams1.Length > 0 && !haveSameTypeParameterNames(typeParams1, typeParams2))


typeParams1.Length > 0

Can this be false? #Closed

The thread is marked as resolved, but I do not see any response to the question. It was about typeParams1.Length > 0 condition, BTW.

You commented on commit 3, but this was fixed later on

AlekseyTs · 2025-08-02T02:36:54Z

src/Compilers/CSharp/Portable/Symbols/MemberSignatureComparer.cs

            bool considerDefaultValues = false,
-            TypeCompareKind typeComparison = TypeCompareKind.IgnoreDynamic | TypeCompareKind.IgnoreNativeIntegers)
+            TypeCompareKind typeComparison = TypeCompareKind.IgnoreDynamic | TypeCompareKind.IgnoreNativeIntegers,
+            bool considerParameterNames = false,


considerParameterNames

It is not obvious from this name, in fact it is unexpected, that this value has any impact on type parameter comparison #Closed

Consider renaming

AlekseyTs · 2025-08-02T02:41:08Z

src/Compilers/CSharp/Portable/Symbols/MemberSignatureComparer.cs

            }

-            return !_considerTypeConstraints || HaveSameConstraints(member1, typeMap1, member2, typeMap2);
+            return !_considerTypeConstraints || HaveSameConstraints(member1, typeMap1, member2, typeMap2, ignoreNullability: (_typeComparison & TypeCompareKind.IgnoreNullableModifiersForReferenceTypes) != 0);


(_typeComparison & TypeCompareKind.IgnoreNullableModifiersForReferenceTypes) != 0

This value makes sense, however, I am curious whether any of the existing comparers might change behavior now. #Closed

None of the existing comparers used considerTypeConstraints (they all use false)

AlekseyTs · 2025-08-02T02:44:06Z

src/Compilers/CSharp/Portable/Symbols/MemberSignatureComparer.cs

+                    return false;
+                }
+
+                var comparer = CommonAttributeDataComparer.InstanceIgnoringNamedArgumentOrder;


InstanceIgnoringNamedArgumentOrder

This makes sense for the extensions scenario, but is not obvious from the API perspective. It might be good to add a comment for considerAttributes parameter. #Closed

AlekseyTs · 2025-08-02T02:49:58Z

src/Compilers/CSharp/Portable/Symbols/MemberSignatureComparer.cs

        }

-        private static bool HaveSameConstraints(Symbol member1, TypeMap? typeMap1, Symbol member2, TypeMap? typeMap2)
+        private static bool HaveSameConstraints(Symbol member1, TypeMap? typeMap1, Symbol member2, TypeMap? typeMap2, bool ignoreNullability = true)


bool ignoreNullability = true

I think it would be better to make this parameter required here and in other signature where we add it. #Closed

AlekseyTs · 2025-08-02T02:51:22Z

        return HaveSameTypeConstraints(typeParameter1, typeMap1, typeParameter2, typeMap2, SymbolEqualityComparer.IgnoringDynamicTupleNamesAndNullability);

Shouldn't this value be adjusted? #Closed

Refers to: src/Compilers/CSharp/Portable/Symbols/MemberSignatureComparer.cs:792 in 7f543e0. [](commit_id = 7f543e0, deletion_comment = False)

AlekseyTs · 2025-08-02T02:52:50Z

Are grouping collisions going to be handled in a separate PR? #Closed

AlekseyTs · 2025-08-02T02:59:44Z

src/Compilers/CSharp/Portable/Symbols/MemberSymbolExtensions.cs

                    return ((PropertySymbol)member).Parameters;
                case SymbolKind.Event:
                    return ImmutableArray<ParameterSymbol>.Empty;
+                case SymbolKind.NamedType:


case SymbolKind.NamedType:

It looks like change is done for the benefit of one call site, that can conditionally special case extensions (based on explicit request). It is, however, not obvious that all other call sites would want this behavior. I suggest leaving this general helper unchanged. #Closed

AlekseyTs · 2025-08-02T03:00:30Z

src/Compilers/CSharp/Portable/Symbols/MemberSymbolExtensions.cs

                case SymbolKind.Event:
                case SymbolKind.Field:
                    return 0;
+                case SymbolKind.NamedType:


case SymbolKind.NamedType:

Same comment as above #Closed

AlekseyTs · 2025-08-02T03:03:53Z

src/Compilers/CSharp/Portable/Symbols/Source/ExtensionGroupingInfo.cs


+        /// <summary>
+        /// Reports a diagnostic when two extension blocks grouped into a single marker type have different C#-level signatures.
+        /// Note: It's fine for two extension blocks with different IL-level signatures to be grouped into the same grouping type, so we don't check for collisions there.


so we don't check for collisions there

It is not clear whether a statement is made that collisions in grouping type are impossible to occur. If it is, I think it is incorrect and collisions checks for grouping types are also necessary. #Closed

AlekseyTs · 2025-08-02T03:08:23Z

src/Compilers/CSharp/Portable/Symbols/Source/SourceNamedTypeSymbol_Extension.cs

-                    var stringBuilder = PooledStringBuilder.GetInstance();
-                    appendAttribute(attribute, stringBuilder.Builder);
-                    attributesBuilder.Add(stringBuilder.ToStringAndFree());
+                    if (!attribute.IsConditionallyOmitted)


if (!attribute.IsConditionallyOmitted)

Is this taken into consideration when we check for collisions? #Closed

Yes, it is considered in CommonAttributeDataComparer.Equals (that's what brought this issue to my attention). Grouping_39 illustrates.

Yes, it is considered in CommonAttributeDataComparer.Equals

It looks like it is considered as part of equality of the attribute. But for our purposes, it feels like conditionally omitted attributes should be out of collision check. Since they are not going to be emitted, no real difference that can come from them, or we should not be ignoring them here. I am leaning towards ignoring though.

AlekseyTs · 2025-08-02T03:11:12Z

Done with review pass (commit 1), tests are not reviewed #Closed

333fred · 2025-08-06T21:18:15Z

src/Compilers/CSharp/Portable/Symbols/Source/ExtensionGroupingInfo.cs

+            if (parameter1 is null || parameter2 is null)
+            {
+                return parameter1 is null && parameter2 is null;
+            }


Nit, think this would be more clearly expressed as:

Suggested change

if (parameter1 is null || parameter2 is null)

{

return parameter1 is null && parameter2 is null;

}

if (parameter1 is null)

{

return parameter2 is null;

}

else if (parameter2 is null)

{

return false;

}

``` #Resolved

333fred · 2025-08-06T21:20:35Z

src/Compilers/CSharp/Portable/Symbols/Source/ExtensionGroupingInfo.cs

+                return parameter1 is null && parameter2 is null;
+            }
+
+            if (!MemberSignatureComparer.HaveSameParameterType(parameter1, typeMap1, parameter2, typeMap2,


Should we try and order this after the cheap checks, like name/declared scope? #Resolved

333fred · 2025-08-06T21:33:23Z

src/Compilers/CSharp/Portable/CSharpResources.resx

    <value>Interpolated string handler arguments are not allowed in this context.</value>
  </data>
+  <data name="ERR_ExtensionBlockCollision" xml:space="preserve">
+    <value>This extension block collides with another extension block. They result in conflicting content-based type names in metadata.</value>


I don't have an immediate suggestion for the wording, but is there something we can tell users to try in this case? #Resolved

333fred · 2025-08-06T21:35:38Z

src/Compilers/CSharp/Test/Emit3/Semantics/ExtensionTests2.cs

+    [Fact]
+    public void Grouping_09()
+    {
+        // attribute on parameter vs. different attribute


Suggested change

// attribute on parameter vs. different attribute

// attribute on parameter vs. different parameter value

``` #Resolved

333fred · 2025-08-06T21:49:03Z

src/Compilers/CSharp/Test/Emit3/Semantics/ExtensionTests2.cs

Consider testing object vs dynamic #Resolved

AlekseyTs · 2025-08-07T02:35:37Z

src/Compilers/CSharp/Portable/Symbols/TypeSymbol.cs

                var typeMap2 = new TypeMap(typeParameters2, indexedTypeParameters, allowAlpha: true);

                // Report any mismatched method constraints.
+                var compareKind = TypeCompareKind.IgnoreDynamicAndTupleNames | TypeCompareKind.IgnoreNullableModifiersForReferenceTypes;


var

const? #Closed

AlekseyTs · 2025-08-07T04:05:11Z

src/Compilers/CSharp/Portable/Symbols/Metadata/PE/PENamedTypeSymbol.cs

                var containingTypeMap = new TypeMap(containingTypeParameters, IndexedTypeParameterSymbol.Take(n), allowAlpha: false);
                var nestedTypeMap = new TypeMap(nestedTypeParameters, IndexedTypeParameterSymbol.Take(nestedTypeParameters.Length), allowAlpha: false);

+                var compareKind = TypeCompareKind.IgnoreDynamicAndTupleNames | TypeCompareKind.IgnoreNullableModifiersForReferenceTypes;


var

const #Closed

AlekseyTs · 2025-08-07T04:09:47Z

src/Compilers/CSharp/Portable/Symbols/Source/ExtensionGroupingInfo.cs

+
+            TypeMap? typeMap1 = MemberSignatureComparer.GetTypeMap(extension1);
+            TypeMap? typeMap2 = MemberSignatureComparer.GetTypeMap(extension2);
+            if (extension1.Arity != extension2.Arity)


if (extension1.Arity != extension2.Arity)

Consider doing this check before allocating type maps #Closed

AlekseyTs · 2025-08-07T04:11:56Z

src/Compilers/CSharp/Portable/Symbols/Source/ExtensionGroupingInfo.cs

+
+            TypeMap? typeMap1 = MemberSignatureComparer.GetTypeMap(extension1);
+            TypeMap? typeMap2 = MemberSignatureComparer.GetTypeMap(extension2);
+            if (extension1.Arity != extension2.Arity)


if (extension1.Arity != extension2.Arity)

Consider doing this check before allocating type maps #Closed

AlekseyTs · 2025-08-07T04:25:49Z

src/Compilers/CSharp/Portable/Symbols/Source/SourceNamedTypeSymbol_Extension.cs

                {
                    var stringBuilder = PooledStringBuilder.GetInstance();
-                    appendTypeWithAnnotation(contraintTypes[i], stringBuilder.Builder);
+                    appendType(constraintTypes[i].Type, stringBuilder.Builder);


appendType(constraintTypes[i].Type, stringBuilder.Builder);

Do we care about nullability of this type? #Closed

No, we don't care about top-level nullability annotations on each type constraint.
We don't emit one annotation per type constraint, we only emit one for the whole type parameter.
Similarly MemberSignatureComparer.HaveSameConstraints performs a single top-level nullability check per type parameter.
And that's why I changed the raw marker name to use "notnull", "maybenull" (invented keyword) or nothing (for oblivious).

No, we don't care about top-level nullability annotations on each type constraint.

I am not sure about that. For example, given the following C# code:

class C<T> where T : C1?, I1, I2? {} class C1{} interface I1{} interface I2{}

The following metadata are generated:

.class private auto ansi beforefieldinit C`1<(C1, I1, I2) T> extends [mscorlib]System.Object { .param constraint T, C1 .custom instance void System.Runtime.CompilerServices.NullableAttribute::.ctor(uint8) = ( 01 00 02 00 00 ) .param constraint T, I1 .custom instance void System.Runtime.CompilerServices.NullableAttribute::.ctor(uint8) = ( 01 00 01 00 00 ) .param constraint T, I2 .custom instance void System.Runtime.CompilerServices.NullableAttribute::.ctor(uint8) = ( 01 00 02 00 00 )

It looks like top level nullability of type constraints affects metadata, therefore, we are supposed to care about it.

We also should care about notnull constraint, but that is a different thing and it has its own impact on metadata.

That said, I think a change to this line should be reverted unless you can demonstrate that the old behavior leads to an incorrect result.

AlekseyTs · 2025-08-07T04:27:05Z

src/Compilers/CSharp/Portable/Symbols/Source/SourceOrdinaryMethodSymbol.cs

            var typeMap2 = new TypeMap(typeParameters2, indexedTypeParameters, allowAlpha: true);

            // Report any mismatched method constraints.
+            var typeComparison = TypeCompareKind.IgnoreDynamicAndTupleNames | TypeCompareKind.IgnoreNullableModifiersForReferenceTypes;


var

const? #Closed

AlekseyTs · 2025-08-07T04:30:16Z

src/ExpressionEvaluator/CSharp/Source/ExpressionCompiler/CompilationContext.cs

            var desiredTypeMap = new TypeMap(desiredTypeParameters, indexedTypeParameters, allowAlpha: true);

-            return MemberSignatureComparer.HaveSameConstraints(candidateTypeParameters, candidateTypeMap, desiredTypeParameters, desiredTypeMap);
+            var typeComparison = TypeCompareKind.IgnoreDynamicAndTupleNames | TypeCompareKind.IgnoreNullableModifiersForReferenceTypes;


var

const? #Closed

AlekseyTs · 2025-08-07T04:41:59Z

Done with review pass (commit 10), tests are not reviewed #Closed

AlekseyTs · 2025-08-07T10:39:28Z

src/Compilers/Core/Portable/Symbols/Attributes/CommonAttributeDataComparer.cs

+                {
+                    if (x.Kind == TypedConstantKind.Type && y.Kind == TypedConstantKind.Type)
+                    {
+                        return x.ValueInternal is ISymbolInternal xType && y.ValueInternal is ISymbolInternal yType && xType.Equals(yType, TypeCompareKind.AllIgnoreOptions);


AllIgnoreOptions

I do not remember whether we should worry about custom modifiers here (modopt/modreq). They are probably not supported in the attribute encoding, but it would be good to confirm. #Closed

Looked at TypeNameDecoder (the decoding counterpart to TypeNameSerializer) and didn't see any handle for modifiers. Thanks

AlekseyTs · 2025-08-07T10:50:20Z

src/Compilers/CSharp/Portable/Symbols/MemberSignatureComparer.cs

        }

-        public static bool HaveSameNullabilityInConstraints(TypeParameterSymbol typeParameter1, TypeMap typeMap1, TypeParameterSymbol typeParameter2, TypeMap typeMap2)
+        public static bool HaveSameNullabilityInConstraints(TypeParameterSymbol typeParameter1, TypeMap? typeMap1, TypeParameterSymbol typeParameter2, TypeMap? typeMap2, TypeCompareKind typeComparison)


TypeCompareKind typeComparison

Looking at this method more, I realized that it is probably not appropriate to let user control the comparison type used by this method because the supplied value might not be suitable for the task that the method is supposed to perform. I suggest reverting changes to this method and not using it for the purpose of this PR. Instead the top level nullability comparison can be done explicitly in HaveSameCSharpSignature helper. It is already doing the other checks by calling HaveSameConstraints. #Closed

AlekseyTs · 2025-08-07T11:06:16Z

Done with review pass (commit 11), tests are not reviewed #Closed

AlekseyTs

LGTM (commit 13). I didn't do a thorough review of tests, relying on Fred's sign-off in this regard.

AlekseyTs · 2025-08-08T04:27:56Z

src/Compilers/CSharp/Portable/Symbols/Source/ExtensionGroupingInfo.cs

+            TypeMap? typeMap1 = MemberSignatureComparer.GetTypeMap(extension1);
+            TypeMap? typeMap2 = MemberSignatureComparer.GetTypeMap(extension2);
+            if (extension1.Arity > 0
+                && !MemberSignatureComparer.HaveSameConstraints(extension1.TypeParameters, typeMap1, extension2.TypeParameters, typeMap2, TypeCompareKind.AllIgnoreOptions))


AllIgnoreOptions

CLRSignatureCompareOptions

AlekseyTs · 2025-08-08T04:28:12Z

src/Compilers/CSharp/Portable/Symbols/Source/ExtensionGroupingInfo.cs

+
+            if (!MemberSignatureComparer.HaveSameParameterType(parameter1, typeMap1, parameter2, typeMap2,
+                refKindCompareMode: MemberSignatureComparer.RefKindCompareMode.IgnoreRefKind,
+                considerDefaultValues: false, TypeCompareKind.AllIgnoreOptions))


AllIgnoreOptions

CLRSignatureCompareOptions

jcouv self-assigned this Jul 31, 2025

jcouv added Area-Compilers Feature - Extension Everything The extension everything feature labels Jul 31, 2025

jcouv force-pushed the extensions-collisions branch 3 times, most recently from 4e1d448 to 9e42d84 Compare August 1, 2025 02:59

jcouv commented Aug 1, 2025

View reviewed changes

jcouv force-pushed the extensions-collisions branch 2 times, most recently from 2bd8055 to ea0615f Compare August 1, 2025 22:05

jcouv changed the title ~~Extensions: check for grouping type collisions~~ Extensions: check for marker collisions Aug 1, 2025

Extensions: check for marker collisions

7f543e0

jcouv force-pushed the extensions-collisions branch from ea0615f to 7f543e0 Compare August 1, 2025 22:24

jcouv marked this pull request as ready for review August 2, 2025 00:39

jcouv requested a review from a team as a code owner August 2, 2025 00:39

AlekseyTs reviewed Aug 2, 2025

View reviewed changes

333fred reviewed Aug 6, 2025

View reviewed changes

Address feedback

9befd0c

AlekseyTs reviewed Aug 7, 2025

View reviewed changes

jcouv requested a review from 333fred August 7, 2025 02:37

AlekseyTs reviewed Aug 7, 2025

View reviewed changes

Address feedback

c0ed7ed

jcouv requested a review from AlekseyTs August 7, 2025 06:11

333fred approved these changes Aug 7, 2025

View reviewed changes

build-analysis bot mentioned this pull request Aug 7, 2025

The active test run was aborted. Reason: Test host process crashed dotnet/dnceng#451

Closed

3 tasks

AlekseyTs reviewed Aug 7, 2025

View reviewed changes

Address feedback

e336ac7

333fred approved these changes Aug 7, 2025

View reviewed changes

Test fixup

3bf4650

AlekseyTs approved these changes Aug 7, 2025

View reviewed changes

jcouv merged commit 3e5a856 into dotnet:features/extensions Aug 7, 2025
28 checks passed

jcouv deleted the extensions-collisions branch August 7, 2025 23:50

AlekseyTs reviewed Aug 8, 2025

View reviewed changes

jcouv mentioned this pull request Aug 12, 2025

Extensions: Address follow-ups related to collection expressions #79877

Merged

This was referenced Aug 19, 2025

[Automated] PRs inserted in VS build main-10918.105 #79952

Closed

[Automated] PRs inserted in VS build feature.debugger.main-10918.21 #79956

Closed

[Automated] PRs inserted in VS build feature.Wix5-10921.95 #80011

Closed

-            if (parameter1 is null || parameter2 is null)
-            {
-                return parameter1 is null && parameter2 is null;
-            }
+            if (parameter1 is null)
+            {
+                return parameter2 is null;
+            }
+            else if (parameter2 is null)
+            {
+                return false;
+            }
+``` #Resolved

	// attribute on parameter vs. different attribute
	// attribute on parameter vs. different parameter value
	``` #Resolved

Extensions: check for collisions #79702

Extensions: check for collisions #79702

Uh oh!

Conversation

jcouv commented Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jcouv Aug 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs commented Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AlekseyTs Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jcouv Aug 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Aug 6, 2025

Choose a reason for hiding this comment

Uh oh!

jcouv Aug 6, 2025

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Aug 2, 2025

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jcouv Aug 2, 2025

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs commented Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AlekseyTs commented Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AlekseyTs Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jcouv commented Jul 31, 2025 •

edited

Loading

jcouv Aug 1, 2025 •

edited

Loading

AlekseyTs commented Aug 2, 2025 •

edited

Loading

AlekseyTs Aug 2, 2025 •

edited

Loading

jcouv Aug 5, 2025 •

edited

Loading

AlekseyTs Aug 2, 2025 •

edited

Loading

AlekseyTs Aug 2, 2025 •

edited

Loading

AlekseyTs Aug 2, 2025 •

edited

Loading

AlekseyTs Aug 2, 2025 •

edited

Loading

AlekseyTs Aug 2, 2025 •

edited

Loading

AlekseyTs Aug 2, 2025 •

edited

Loading

AlekseyTs Aug 2, 2025 •

edited

Loading

AlekseyTs commented Aug 2, 2025 •

edited

Loading

AlekseyTs commented Aug 2, 2025 •

edited

Loading

AlekseyTs Aug 2, 2025 •

edited

Loading

AlekseyTs Aug 2, 2025 •

edited

Loading

AlekseyTs Aug 2, 2025 •

edited

Loading

AlekseyTs Aug 2, 2025 •

edited

Loading

AlekseyTs Aug 3, 2025 •

edited

Loading

AlekseyTs commented Aug 2, 2025 •

edited

Loading

333fred Aug 6, 2025 •

edited by jcouv

Loading

333fred Aug 6, 2025 •

edited by jcouv

Loading

333fred Aug 6, 2025 •

edited by jcouv

Loading

333fred Aug 6, 2025 •

edited by jcouv

Loading

333fred Aug 6, 2025 •

edited by jcouv

Loading

AlekseyTs Aug 7, 2025 •

edited

Loading

AlekseyTs Aug 7, 2025 •

edited

Loading

AlekseyTs Aug 7, 2025 •

edited

Loading

AlekseyTs Aug 7, 2025 •

edited

Loading

AlekseyTs Aug 7, 2025 •

edited

Loading

AlekseyTs Aug 7, 2025 •

edited

Loading