[SR-11588]Warn about derived Hashable implementation if there’s a custom Equatable #27801

JGiola · 2019-10-20T21:26:57Z

This is a first approach to add the desired warning for custom Equatable implementation during Hashable synthesis.

It’s working for struct just fine but it crashes when running test/Sema/implementation-only-import-in-decls.swift for some reason it don’t like enum types.

Other improvements before merging are increase the test coverage in test/Sema/diag_custom_equatable_syntheszied_hashable.swift and replicate the same warning in the opposite direction for custom Hashable implementation during Equatable synthesis.

Resolves SR-11588.

theblixguy · 2019-10-20T23:06:52Z

include/swift/AST/DiagnosticsSema.def

+WARNING(hashable_customEquatable, none,
+        "Automatically generated 'Hashable' implementation for type %0 "
+        "may not match the behavior of custom '==' operator",
+        (Type))


Can you give the diagnostic identifier a more descriptive name? Also, please use lowercase words only. For example: synthesized_hashable_may_not_match_custom_equatable.

Diagnostic text must start with a lowercase letter.

Can you move the argument (aka (Type)) to the line above since it can fit there?

theblixguy · 2019-10-20T23:07:52Z

include/swift/AST/DiagnosticsSema.def

+        "may not match the behavior of custom '==' operator",
+        (Type))
+NOTE(add_custom_hashable, none,
+     "Add a custom 'hash(into:)' method", ())


Same here as well - this should start with a lowercase letter.

theblixguy · 2019-10-20T23:17:10Z

lib/Sema/DerivedConformanceEquatableHashable.cpp

-        ConformanceDecl->diagnose(diag::type_does_not_conform,
-                                  Nominal->getDeclaredType(),
-                                  hashableProto->getDeclaredType());
+      auto *DC = ConformanceDecl->getDeclContext();


Nit: Maybe conformanceDC?

theblixguy · 2019-10-20T23:18:20Z

lib/Sema/DerivedConformanceEquatableHashable.cpp

-                                  Nominal->getDeclaredType(),
-                                  hashableProto->getDeclaredType());
+      auto *DC = ConformanceDecl->getDeclContext();
+      auto type = Nominal->getDeclaredType();


Nit: nominalTy/nominalType?

theblixguy · 2019-10-20T23:32:04Z

Please run clang-format as well to ensure your changes fit within the 80-column limit!

It’s working for struct just fine but it crashes when running test/Sema/implementation-only-import-in-decls.swift for some reason it don’t like enum types.

Can you share the stack trace?

stephentyrone · 2019-10-21T17:37:16Z

cc @lorentey

JGiola · 2019-10-21T19:09:00Z

Please run clang-format as well to ensure your changes fit within the 80-column limit!

I’ve run it on the file but it has changed a lot of formatting in the file apart the block I’ve added. It’s okay to add all the changes or is better to revert all the other changes and keep only my formatted block?

JGiola · 2019-10-21T19:20:19Z

Can you share the stack trace?

Here it is.

1.      Swift version 5.1.1-dev (LLVM f4c2b4eca6, Swift 32c1b05168)
2.      While type-checking protocol conformance to 'Hashable' (in module 'Swift') for type 'TestRawType' (declared at [/swift-source/swift/test/Sema/implementation-only-import-in-decls.swift:65:8 - line:68:1] RangeText="enum TestRawType: IntLike { // expected-error {{cannot use struct 'IntLike' here; 'BADLibrary' has been imported as implementation-only}}
  case x = 1
  // FIXME: expected-error@-1 {{cannot use conformance of 'IntLike' to 'Equatable' here; 'BADLibrary' has been imported as implementation-only}}
")
0  swiftc                   0x000000010d1be0c5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1  swiftc                   0x000000010d1bd355 llvm::sys::RunSignalHandlers() + 85
2  swiftc                   0x000000010d1be6b8 SignalHandler(int) + 264
3  libsystem_platform.dylib 0x00007fff57d2bb5d _sigtramp + 29
4  libsystem_platform.dylib 0x00007ffee841d608 _sigtramp + 2423200456
5  libsystem_c.dylib        0x00007fff57be56a6 abort + 127
6  libsystem_c.dylib        0x00007fff57bae20d basename_r + 0
7  swiftc                   0x0000000109fb1b77 swift::RootProtocolConformance::getWitnessDeclRef(swift::ValueDecl*) const + 167
8  swiftc                   0x0000000109fb03dd swift::ProtocolConformance::getWitnessDeclRef(swift::ValueDecl*) const + 93
9  swiftc                   0x0000000109fb0366 swift::ProtocolConformanceRef::getWitnessByName(swift::Type, swift::DeclName) const + 198
10 swiftc                   0x0000000109117245 swift::DerivedConformance::deriveHashable(swift::ValueDecl*) + 1093
11 swiftc                   0x00000001093205bb swift::TypeChecker::deriveProtocolRequirement(swift::DeclContext*, swift::NominalTypeDecl*, swift::ValueDecl*) + 315
12 swiftc                   0x0000000109320323 swift::ConformanceChecker::resolveWitnessViaDerivation(swift::ValueDecl*) + 275
13 swiftc                   0x0000000109320f11 swift::ConformanceChecker::resolveWitnessTryingAllStrategies(swift::ValueDecl*) + 289
14 swiftc                   0x00000001093221e1 swift::ConformanceChecker::resolveValueWitnesses() + 401
15 swiftc                   0x000000010931a8a9 swift::ConformanceChecker::checkConformance(swift::MissingWitnessDiagnosisKind) + 553
16 swiftc                   0x00000001093185dc swift::MultiConformanceChecker::checkIndividualConformance(swift::NormalProtocolConformance*, bool) + 3292
17 swiftc                   0x0000000109317620 swift::MultiConformanceChecker::checkAllConformances() + 144
18 swiftc                   0x00000001093242fb swift::TypeChecker::checkConformancesInContext(swift::DeclContext*, swift::IterableDeclContext*) + 1035
19 swiftc                   0x0000000109479cc6 typeCheckFunctionsAndExternalDecls(swift::SourceFile&, swift::TypeChecker&) + 470
20 swiftc                   0x000000010947a459 swift::performTypeChecking(swift::SourceFile&, swift::TopLevelContext&, swift::OptionSet<swift::TypeCheckingFlags, unsigned int>, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) + 1017
21 swiftc                   0x0000000107e68735 swift::CompilerInstance::parseAndTypeCheckMainFileUpTo(swift::SourceFile::ASTStage_t, swift::OptionSet<swift::TypeCheckingFlags, unsigned int>) + 965
22 swiftc                   0x0000000107e66bd0 swift::CompilerInstance::parseAndCheckTypesUpTo(swift::CompilerInstance::ImplicitImports const&, swift::SourceFile::ASTStage_t) + 384
23 swiftc                   0x0000000107e66007 swift::CompilerInstance::performSemaUpTo(swift::SourceFile::ASTStage_t) + 807
24 swiftc                   0x0000000107e6606a swift::CompilerInstance::performSema() + 26
25 swiftc                   0x00000001078f3509 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 457
26 swiftc                   0x00000001078f2589 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 2121
27 swiftc                   0x00000001077dfee4 run_driver(llvm::StringRef, llvm::ArrayRef<char const*>) + 292
28 swiftc                   0x00000001077df1f3 main + 1875
29 libdyld.dylib            0x00007fff57b403d5 start + 1
30 libdyld.dylib            0x0000000000000013 start + 2823552063

theblixguy · 2019-10-21T20:49:48Z

lib/Sema/DerivedConformanceEquatableHashable.cpp

+                                            equalsName);
+
+        auto equalsDeclaration = witness.getDecl();
+        if (!equalsDeclaration->isImplicit()) {


Suggested change

if (!equalsDeclaration->isImplicit()) {

if (equalsDeclaration && !equalsDeclaration->isImplicit()) {

just in case we don't have a decl. Also, check if it fixes that crash

I added the check but the crash remains, but I’ve noted that I’ve missed a line in the stack trace Assertion failed: (!witnessDC->isInnermostContextGeneric()), function getWitnessDeclRef, file /swift-source/swift/lib/AST/ProtocolConformance.cpp, line 947. Stack dump:
Seems that I’m using something wrong in getting the witness of the == declaration. But I don’t get what is wrong.

Can you run the compiler with the debugger attached (copy the giant command-line dump you saw in the backtrace, then put lldb in front of it and -- after the executable name, then execute it and use the command run) and then, once it crashes, use the command e witnessDC->dumpContext() to see what the witnessDC is? That might give us a better idea of what's going wrong.

No my bad, discard this message 😳

In that point it seems that witnessDC is:

(lldb) e witnessDC->dumpContext() 0x118815ca0 Module name=Swift 0x118815d60 FileUnit file="/swift-source/build/Ninja-RelWithDebInfoAssert+swift-DebugAssert/swift-macosx-x86_64/lib/swift/macosx/Swift.swiftmodule/x86_64.swiftmodule" 0x118044b40 AbstractFunctionDecl name===(_:_:) : <T where T : RawRepresentable, T.RawValue : Equatable> (T, T) -> Bool

I've tried to hunt up the stack to gather some other context, these are the variables inside my block in DerivedConformanceEquatableHashable.cpp

e eqConformance->dump() (normal_conformance type=TestRawType protocol=Equatable (value req===(_:_:) witness=Swift.(file).==)) e nominalTy->dump() (enum_type decl=main.(file).TestRawType@/swift-source/swift/test/Sema/implementation-only-import-in-decls.swift:65:13)

After stepping in in the getWitnessByName function I found these:

e type.dump() (enum_type decl=main.(file).TestRawType@/swift-source/swift/test/Sema/implementation-only-import-in-decls.swift:65:13) e name.getBaseName() (swift::DeclBaseName) $0 = { Ident = (Pointer = "==") } (lldb) e getConcrete()->dump() (normal_conformance type=TestRawType protocol=Equatable (value req===(_:_:) witness=Swift.(file).==)) e witness (swift::Witness) $1 = { storage = { llvm::pointer_union_detail::PointerUnionMembers<llvm::PointerUnion<swift::ValueDecl *, swift::Witness::StoredWitness *>, llvm::PointerIntPair<void *, 1, int, llvm::pointer_union_detail::PointerUnionUIntTraits<swift::ValueDecl *, swift::Witness::StoredWitness *>, llvm::PointerIntPairInfo<void *, 1, llvm::pointer_union_detail::PointerUnionUIntTraits<swift::ValueDecl *, swift::Witness::StoredWitness *> > >, 0, swift::ValueDecl *, swift::Witness::StoredWitness *> = { llvm::pointer_union_detail::PointerUnionMembers<llvm::PointerUnion<swift::ValueDecl *, swift::Witness::StoredWitness *>, llvm::PointerIntPair<void *, 1, int, llvm::pointer_union_detail::PointerUnionUIntTraits<swift::ValueDecl *, swift::Witness::StoredWitness *>, llvm::PointerIntPairInfo<void *, 1, llvm::pointer_union_detail::PointerUnionUIntTraits<swift::ValueDecl *, swift::Witness::StoredWitness *> > >, 1, swift::Witness::StoredWitness *> = { llvm::pointer_union_detail::PointerUnionMembers<llvm::PointerUnion<swift::ValueDecl *, swift::Witness::StoredWitness *>, llvm::PointerIntPair<void *, 1, int, llvm::pointer_union_detail::PointerUnionUIntTraits<swift::ValueDecl *, swift::Witness::StoredWitness *>, llvm::PointerIntPairInfo<void *, 1, llvm::pointer_union_detail::PointerUnionUIntTraits<swift::ValueDecl *, swift::Witness::StoredWitness *> > >, 2> = { Val = (Value = 4700503004) } } } } }

I’ve recreated the problem, it seems that if the Equatable conformance is declared in a different module, and the type extend that, the eqConformance is not valid to generate a witness.
Anyone knows how can I catch that? Using lldb I haven’t find much differences between the tests that I can use to disambiguate them and the methods of eqConformance don’t seems to have that particular catch available, or at least not to my eyes.

I think that the correct flow is that in the if that checks that the conformance exists must check even if the conformance is inside my module before finding the witness (even because is nonsensical to add a warning in another module right?).

JGiola · 2019-12-06T20:10:02Z

@DougGregor sorry to ping, but I've read in the CODE_OWNERS file that you are associated with the Sema. Do you know how can I catch that the equality conformance is implemented in another module and that I cannot get the witness for it?

I‘ve tried to look everywhere but I’m not seeing anything useful for a check against it :(

beccadax · 2020-05-12T23:00:50Z

@swift-ci please smoke test

beccadax · 2020-05-12T22:58:38Z

test/Sema/diag_custom_equatable_syntheszied_hashable.swift

+
+enum ImportedConformance: ImplicitEquatable {
+  case x = 1
+}


If you don't already have something like this, I'd suggest adding test cases like these (plus cross-file and perhaps cross-module variants):

protocol DefaultedImplementationProtocol: Equatable {} extension DefaultedImplementationProtocol { static func == (lhs: Self, rhs: Self) -> Bool { true } } struct DefaultedImplementation: DefaultedImplementationProtocol, Hashable { let a: Int }

protocol ConditionalImplementationProtocol {} extension ConditionalImplementationProtocol where Self: Equatable { static func == (lhs: Self, rhs: Self) -> Bool { true } } struct ConditionalImplementation: ConditionalImplementationProtocol, Hashable { let a: Int }

protocol ConditionalHashableImplementationProtocol {} extension ConditionalHashableImplementationProtocol where Self: Equatable { static func == (lhs: Self, rhs: Self) -> Bool { true } } extension ConditionalHashableImplementationProtocol where Self: Hashable { func hash(into hasher: Hasher) {} } struct ConditionalHashableImplementation: ConditionalHashableImplementationProtocol, Hashable { let a: Int }

I haven't included expected-warning in these test cases because I haven't thought much about whether we should have warnings in them (and whether there might be cases, like "all of the properties are requirements of the protocol, so I assume Equatable checks them", where we shouldn't warn); you should look at the change's behavior in these cases and similar ones to make sure you're happy with it.

(Also, typo: I think the "z" is in the wrong place in this filename.)

Thanks for the catch on the typo in the filename! I've added your example cases for not forgetting them. I will iterate over them and add the correct variant for out of file and cross module. But I'm always stuck on the crasher that I'm getting for asking the witness declaration of the equals function when is cross module for an enum. I don't know what check I must execute to avoid the !witnessDC->isInnermostContextGeneric() assertion in the AST/ProtocolConformance.cpp file.

shahmishal · 2020-10-01T06:54:42Z

Please update the base branch to main by Oct 5th otherwise the pull request will be closed automatically.

How to change the base branch: (Link)
More detail about the branch update: (Link)

JGiola · 2021-06-04T07:48:08Z

@beccadax hi, sorry to ping you, I've finally solved the issue and on my mac all the tests are running fine. There is more changes I have to do?

beccadax · 2021-06-06T07:51:10Z

@swift-ci please test

swift-ci · 2021-06-06T09:50:52Z

Build failed
Swift Test Linux Platform
Git Sha - 3778c30ec33b56fd6a73050c0ebba5fd803a53a0

swift-ci · 2021-06-06T11:32:45Z

Build failed
Swift Test OS X Platform
Git Sha - 3778c30ec33b56fd6a73050c0ebba5fd803a53a0

JGiola · 2021-08-24T19:28:18Z

I've rebased the repo and run all the tests with utils/run-test --lit ../llvm-project/llvm/utils/lit/lit.py ../build/Ninja-RelWithDebInfoAssert/swift-macosx-$(uname -m)/test-macosx-$(uname -m) and nothing is breaking this time.

xwu · 2021-08-25T04:07:04Z

@swift-ci please test

xwu · 2021-08-25T04:08:55Z

include/swift/AST/DiagnosticsSema.def

@@ -5675,6 +5675,11 @@ ERROR(override_nsobject_hash_error,none,
      "'NSObject.hash(into:)' is not overridable; "
      "did you mean to override 'NSObject.hash'?", ())

+WARNING(synthesized_hashable_may_not_match_custom_equatable, none,
+         "automatically generated 'Hashable' implementation for type %0 "


Suggested change

"automatically generated 'Hashable' implementation for type %0 "

"synthesized 'Hashable' implementation for type %0 "

Is there a reason to avoid the commonly used word 'synthesized' here?

xwu · 2021-08-25T04:11:18Z

include/swift/AST/DiagnosticsSema.def

@@ -5675,6 +5675,11 @@ ERROR(override_nsobject_hash_error,none,
      "'NSObject.hash(into:)' is not overridable; "
      "did you mean to override 'NSObject.hash'?", ())

+WARNING(synthesized_hashable_may_not_match_custom_equatable, none,
+         "automatically generated 'Hashable' implementation for type %0 "
+         "may not match the behavior of custom '==' operator", (Type))


Suggested change

"may not match the behavior of custom '==' operator", (Type))

"may not match behavior of custom '==' operator", (Type))

(Reduced written register doesn't use a definite article here.)

More pertinently, is there a word to describe what is meant better than "match"? To me, a simple reading would suggest that 'Hashable' should behave like '==', and of course that doesn't make sense; a reader might ignore the warning because why would they want two disparate things (a protocol and an operator) to "match"?

"be compatible with" might be more precise, but that's still not really actionable for the user unless we spell out what "compatible" actually means. I'm not sure how verbose we want this warning to be, however. Ideally we'd be able to just stick in a reference to some relevant documentation or something.

Maybe, “aligned”? Instead of “behavior,” maybe “semantics”? Not sure but I think we can get a little closer with some wordsmithing.

So if we were going to really spell it out precisely, what would we say? Let's start with that and try to back off. Something like

"Any two values that compare equal with == must also have the same hash; because you have provided a custom == implementation for %0, you should also provide a custom implementation of Hashable."

Yeah, you beat me to the punch. I was going to suggest something similar:

"custom 'Equatable' conformance without custom 'Hashable' conformance may cause equivalent values to have different hashes" (fixit: insert missing declarations required by 'Hashable')

[Edit: or, "custom 'Equatable' conformance with synthesized 'Hashable' conformance may cause unexpected behavior; equivalent values must have same hash"]

xwu · 2021-08-25T04:11:51Z

lib/Sema/DerivedConformanceEquatableHashable.cpp

@@ -1022,6 +1022,27 @@ ValueDecl *DerivedConformance::deriveHashable(ValueDecl *requirement) {
      if (checkAndDiagnoseDisallowedContext(requirement))
        return nullptr;

+      // Warn the user that having a custom == almost surely require a


Suggested change

// Warn the user that having a custom == almost surely require a

// Warn the user that having a custom == almost surely requires a

xwu · 2021-08-25T04:12:03Z

lib/Sema/DerivedConformanceEquatableHashable.cpp

@@ -1022,6 +1022,27 @@ ValueDecl *DerivedConformance::deriveHashable(ValueDecl *requirement) {
      if (checkAndDiagnoseDisallowedContext(requirement))
        return nullptr;

+      // Warn the user that having a custom == almost surely require a
+      // custom Hashable conformance even if, for source stability reasons,
+      // it will be synthesized


Suggested change

// it will be synthesized

// it will be synthesized.

swift-ci · 2021-08-25T06:11:52Z

Build failed
Swift Test Linux Platform
Git Sha - bdc68ea659ec34c482f1c26facfb65fc90c7750e

swift-ci · 2021-08-25T06:44:43Z

Build failed
Swift Test OS X Platform
Git Sha - bdc68ea659ec34c482f1c26facfb65fc90c7750e

WowbaggersLiquidLunch · 2022-01-10T06:32:33Z

@swift-ci please smoke test

WowbaggersLiquidLunch · 2022-10-14T01:34:36Z

@swift-ci please test

JGiola changed the title ~~Warn about derived Hashable implementation if there’s a custom Equatable~~ [WIP][SR-11588]Warn about derived Hashable implementation if there’s a custom Equatable Oct 20, 2019

theblixguy reviewed Oct 20, 2019

View reviewed changes

JGiola force-pushed the SR-11588 branch from 32c1b05 to c5704e0 Compare October 21, 2019 20:30

theblixguy reviewed Oct 21, 2019

View reviewed changes

JGiola force-pushed the SR-11588 branch 2 times, most recently from 686e192 to cc6e113 Compare October 30, 2019 19:21

JGiola force-pushed the SR-11588 branch 2 times, most recently from 8f73bfb to dffb024 Compare November 11, 2019 23:27

JGiola force-pushed the SR-11588 branch from dffb024 to 73ba445 Compare November 23, 2019 13:07

JGiola force-pushed the SR-11588 branch from 73ba445 to e188cb8 Compare December 4, 2019 23:20

JGiola force-pushed the SR-11588 branch from e188cb8 to 7f2868a Compare December 13, 2019 23:21

JGiola force-pushed the SR-11588 branch 3 times, most recently from 6c76ba5 to afa184f Compare May 12, 2020 21:13

beccadax requested changes May 12, 2020

View reviewed changes

JGiola force-pushed the SR-11588 branch from afa184f to 460c667 Compare May 13, 2020 19:49

JGiola force-pushed the SR-11588 branch from 460c667 to 58b942b Compare July 27, 2020 16:16

JGiola changed the base branch from master to main October 1, 2020 09:15

JGiola force-pushed the SR-11588 branch from 58b942b to b8a9ff4 Compare October 1, 2020 18:25

JGiola force-pushed the SR-11588 branch from b8a9ff4 to b17468b Compare October 21, 2020 19:18

JGiola force-pushed the SR-11588 branch from b17468b to ff49bb3 Compare November 7, 2020 13:05

JGiola force-pushed the SR-11588 branch from ff49bb3 to 1400c8e Compare November 24, 2020 20:37

JGiola force-pushed the SR-11588 branch from 1400c8e to 8f79ae4 Compare December 7, 2020 09:33

JGiola changed the title ~~[WIP][SR-11588]Warn about derived Hashable implementation if there’s a custom Equatable~~ [SR-11588]Warn about derived Hashable implementation if there’s a custom Equatable Jun 2, 2021

JGiola force-pushed the SR-11588 branch from 3778c30 to 945235a Compare August 2, 2021 09:33

JGiola force-pushed the SR-11588 branch from 945235a to bdc68ea Compare August 23, 2021 22:15

xwu reviewed Aug 25, 2021

View reviewed changes

WowbaggersLiquidLunch mentioned this pull request Aug 25, 2021

[WIP][SR-14665] Warn of potentially incorrectly synthesized Equatable conformance for custom Comparable conformance #39047

Draft

JGiola force-pushed the SR-11588 branch 2 times, most recently from 252b0b4 to 76da5ac Compare September 22, 2021 08:22

JGiola force-pushed the SR-11588 branch from 76da5ac to 343f00c Compare November 3, 2021 22:35

JGiola force-pushed the SR-11588 branch from 343f00c to cfd751a Compare December 3, 2021 23:31

This comment has been minimized.

Sign in to view

JGiola force-pushed the SR-11588 branch from cfd751a to 7a378ed Compare January 9, 2022 17:03

JGiola mentioned this pull request Oct 20, 2019

[SR-11588] Warn about derived Hashable implementation if there's a custom Equatable #53993

Open

JGiola force-pushed the SR-11588 branch from 7a378ed to 11e12fc Compare May 19, 2022 14:58

JGiola force-pushed the SR-11588 branch from 11e12fc to 95500bb Compare July 1, 2022 16:33

JGiola force-pushed the SR-11588 branch from 95500bb to d6be703 Compare October 11, 2022 12:46

Warn about derived Hashable implementation if there's a custom Equatable

233b9fc

JGiola force-pushed the SR-11588 branch from d6be703 to 233b9fc Compare April 8, 2025 12:33

JGiola requested review from hborla, slavapestov and xedin as code owners April 8, 2025 12:33

	if (!equalsDeclaration->isImplicit()) {
	if (equalsDeclaration && !equalsDeclaration->isImplicit()) {

	"automatically generated 'Hashable' implementation for type %0 "
	"synthesized 'Hashable' implementation for type %0 "

	"may not match the behavior of custom '==' operator", (Type))
	"may not match behavior of custom '==' operator", (Type))

	// Warn the user that having a custom == almost surely require a
	// Warn the user that having a custom == almost surely requires a

[SR-11588]Warn about derived Hashable implementation if there’s a custom Equatable #27801

Are you sure you want to change the base?

[SR-11588]Warn about derived Hashable implementation if there’s a custom Equatable #27801

Conversation

JGiola commented Oct 20, 2019

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

theblixguy commented Oct 20, 2019 • edited Loading

stephentyrone commented Oct 21, 2019

JGiola commented Oct 21, 2019

JGiola commented Oct 21, 2019

Choose a reason for hiding this comment

JGiola Oct 21, 2019 • edited Loading

Choose a reason for hiding this comment

beccadax Oct 22, 2019 • edited Loading

Choose a reason for hiding this comment

JGiola Oct 22, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JGiola commented Dec 6, 2019

beccadax commented May 12, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shahmishal commented Oct 1, 2020

JGiola commented Jun 4, 2021

beccadax commented Jun 6, 2021

swift-ci commented Jun 6, 2021

swift-ci commented Jun 6, 2021

JGiola commented Aug 24, 2021

xwu commented Aug 25, 2021

xwu Aug 25, 2021 • edited Loading

Choose a reason for hiding this comment

xwu Aug 25, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xwu Aug 25, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

swift-ci commented Aug 25, 2021

swift-ci commented Aug 25, 2021

This comment has been minimized.

WowbaggersLiquidLunch commented Jan 10, 2022

WowbaggersLiquidLunch commented Oct 14, 2022

theblixguy commented Oct 20, 2019 •

edited

Loading

JGiola Oct 21, 2019 •

edited

Loading

beccadax Oct 22, 2019 •

edited

Loading

JGiola Oct 22, 2019 •

edited

Loading

xwu Aug 25, 2021 •

edited

Loading

xwu Aug 25, 2021 •

edited

Loading

xwu Aug 25, 2021 •

edited

Loading