`panic::Location` ordering is defined by pointer ordering, not string ordering

[clarfonthey]

Based upon the definition here:

pub struct Location<'a> {
    // A raw pointer is used rather than a reference because the pointer is valid for one more byte
    // than the length stored in this pointer; the additional byte is the NUL-terminator used by
    // `Location::file_with_nul`.
    filename: NonNull<str>,
    line: u32,
    col: u32,
    _filename: PhantomData<&'a str>,
}

This has a derived Ord (and subtraits) impl, which means it uses the Ord (and subtraits) impl for NonNull<str> instead of str, which uses pointer-based ordering. This feels incorrect, and I noticed it when trying to make its ordering impls const. The utility of making the ordering const is questionable, but regardless, this feels like an incorrect impl.

I'm filing this as an issue since this feels like it deserves a proper libs decision on whether this ordering should be preserved, or updated to be correct. Plus, maybe a crater run to ensure nobody cares about the fact that it uses pointer-ordering instead of string-ordering.

For the PartialEq impl, this doesn't matter because the location string is the same for each file, but for Ord, it definitely does matter.

[ChrisDenton]

I would suspect (though haven't checked) that this was made Ord purely for the sake of containers that require it and nobody particularly cared what that order was.

[Noratrieb]

This used to contain a &str, it was likely broken when it was made null terminated.

[orlp]

I'm filing this as an issue since this feels like it deserves a proper libs decision on whether this ordering should be preserved, or updated to be correct.

I don't think this needs T-libs discussion or a decision, this is simply a bug. The documentation is already crystal clear in what should happen:

Comparisons for equality and ordering are made in file, line, then column priority. Files are compared as strings, not Path, which could be unexpected. See Location::file’s documentation for more discussion.

[clarfonthey]

I feel kind of silly for noticing this issue and filing it here without reading that note in the documentation. Thank you for submitting a PR for a fix; I probably would have done that if I had noticed first. ><

Also, thank you for including Hash in this, since that is relevant too.