`Equals()` and `GetHashCode()` implementations are inconsistent

[dougbu]

SourceLocation.GetHashCode() and SourceLocation.Equals() use different properties, a fairly basic no-no. problems are unlikely unless one of the source locations is corrupt. nonetheless this quirk should be removed.

in particular GetHashCode() ignores LineIndex and CharacterIndex while Equals() includes them in its comparison. Equals() is the odd one out because CompareTo() also ignores LineIndex and CharacterIndex.

e.g. the following test succeeds

// Arrange
var sourceLocationA = new SourceLocation(10, 3, 4);
var sourceLocationB = new SourceLocation(10, 45, 8754);

// Act
var compare = sourceLocationA.CompareTo(sourceLocationB);
var equals = sourceLocationA.Equals(sourceLocationB);
var hashCodeA = sourceLocationA.GetHashCode();
var hashCodeB = sourceLocationB.GetHashCode();

// Assert
Assert.Equal(0, compare);
Assert.False(equals);    // !!!
Assert.Equal(hashCodeA, hashCodeB);

original discussion at #357 (comment)

[Eilon]

That doesn't seem like a real bug, does it? It's perfectly fine to implement GetHashCode() to return 0 and then to implement Equals() to do a proper comparison. Nothing will break. The only contract is that if two instances are compared and have Equals() be true that their GetHashCode() returns the same value.

[dougbu]

I haven't seen anything except Equals() consistency with GetHashCode() but it's possible nothing will break due to that inconsistency here. now a bit more concerned about Equals() returning false in scenarios where CompareTo() returns 0.

[danroth27]

@dougbu Do the Right Thing