`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.