Open Radar

 
Summary:
If Module A defines this operator:

```swift
infix operator <^> { precedence 100 }
```

and then Module B defines this operator:

```swift
infix operator <^> { precedence 110 }
```

then these two modules become incompatible with each other, and attempting to use the `<^>` operator results in the following error messaging:

```
Ambiguous operator declarations found for operator
Operator is not a known binary operator
```

This is made worse by the additional messaging for the ambiguous operator declarations (Two instances of `Found this matching operator declaration`), which simply point at the usage of the operator.

Steps to Reproduce:
1. Create frameworks that both export the same operator with different precedence/associativity settings
2. Try to use the operator when both frameworks are imported

Expected Results:
Ideally: some way to disambiguate the operator definitions
Short term: Better error messaging about where the operators are defined and what the difference is (and possibly how to resolve the issue)

Actual Results:
Ambiguous error messaging that doesn’t explain the issue very well.

Regression:
N/A

Notes:
For a real world example:

Runes (https://github.com/thoughtbot/Runes) is a framework that defines some custom operators for monadic functions
SwiftCheck (https://github.com/typelift/SwiftCheck) is a framework that allows you to do property based testing in Swift. SwiftCheck depends on Swiftz (https://github.com/typelift/Swiftz) a functional programming lib for Swift.

Runes and Swiftz both define operators (`<^>`) for `map`. However, Runes sets the precedence to 130, where Swiftz sets the precedence to 140.

The result of this is that when trying to use SwiftCheck to test Runes, I am unable to, because the operator definitions are ambiguous.

To see this in action, you can look at the `gf-swiftcheck-bugreport` branch of Runes: https://github.com/thoughtbot/Runes/tree/gf-swiftcheck-bugreport