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

[WowbaggersLiquidLunch]

Currently Comparable inherits from Equatable, but does not provide a default implementation for ==, so the compiler synthesizes one composed of member-wise ==s. This leads to a problem where if a type's < is not composed of member-wise inequalities, then <, >, and == can all evaluate to false for some pairs of values, contradicting Comparable's documentation:

Types with Comparable conformance implement the less-than operator (<) and the equal-to operator (==). These two operations impose a strict total order on the values of a type, in which exactly one of the following must be true for any two values a and b:

• a == b
• a < b
• b < a

For example:

struct Length: Comparable {
    enum Unit: Double, Comparable {
        case mm = 0.001
        case m = 1
        case banana = 0.178
    }
    
    let magnitude: Double
    let unit: Unit
    
    static func < (lhs: Self, rhs: Self) -> Bool {
        lhs.magnitude * lhs.unit.rawValue < rhs.magnitude * rhs.unit.rawValue
    }
}

let aBanana = Length(magnitude: 1, unit: .banana)
let oneBanana = Length(magnitude: 0.178, unit: .m)

print(aBanana < oneBanana)  // prints "false", because Length's < says so.
print(aBanana > oneBanana)  // prints "false", because Comparable's default implementation of >(a,b) is <(b,a).
print(aBanana == oneBanana) // prints "false", because the 2 Length instances are not member-wise equal.

Relevant forums discussion: https://forums.swift.org/t/add-default-implementation-of-to-comparable/48832

This bug has previously resulted in incorrect semantic version comparison in SwiftPM (swiftlang/swift-package-manager#3486 and swiftlang/swift-tools-support-core#214)

---

The implementation in this PR is mostly based on #27801. It checks if a Comparable conformance is user-implemented or compiler-synthesized. If it's the former, it presents a warning to the user that the synthesized == might contradict the user-defined <. Probably a better implementation would be checking if a user defined < is composed of (or equivalent to) member-wise inequalities, so it can avoid false positives. However, my C++ skills and my knowledge of the Swift compiler are rather lousy, so I'm not able to code out the better implementation.

---

This PR is currently a work in progress, because I need to add tests to it.

[slavapestov]

DerivedConformance already has a Context instance variable, you can use that (the ASTContext instance is a global singleton).

[slavapestov]

Use getDeclaredInterfaceType() instead

[slavapestov]

It should work to just pass the Identifier directly to getWitnessByName(). It will implicitly convert to a DeclName.

[slavapestov]

You don't need getRValueType() here.

[CodaFi]

How is the user meant to silence this warning if they intend for this behavior?

[WowbaggersLiquidLunch]

@slavapestov I made the changes that you suggested, but I'm not sure if I did them correctly (the last time I used C++ was from 4 years ago). Could you help me check them again?

[WowbaggersLiquidLunch]

How is the user meant to silence this warning if they intend for this behavior?

@CodaFi I don't think the user can silence the warning with the current implementation in this PR. Something like the following code will result in a false-positive warning:

struct IntegerWrapper: Comparable {
    let wrappedInteger: Int
    func < (lhs: Self, rhs: Self) {
        lhs.wrappedInteger < rhs.wrappedInteger
    }
}

even though the code above is correct, and basically the same as what the compiler would have synthesized.

Is there a way to offer user the ability to silence this warning? I'm not familiar with things in the compiler, so any advice would be great!

I think a better solution would be for the compiler to check if the user-implemented < is composed of member-wise inequalities, and don't warn the user if it is. However, right now, I don't know how to write the code for this logic.

[WowbaggersLiquidLunch]

@swift-ci please smoke test