]> git.lizzy.rs Git - rust.git/commit - src/librustc_llvm/build.rs
Auto merge of #73583 - anp:location-eq, r=dtolnay
authorbors <bors@rust-lang.org>
Mon, 27 Jul 2020 22:38:25 +0000 (22:38 +0000)
committerbors <bors@rust-lang.org>
Mon, 27 Jul 2020 22:38:25 +0000 (22:38 +0000)
commit9be8ffcb0206fc1558069a7b4766090df7877659
tree5a58aada4c071bb3997e4f3543ffb69eb6615c48
parent76e83339bb619aba206e5590b1e4b813a154b199
parent416dc4b978e5921cd0b20478a17f048dd378bdff
Auto merge of #73583 - anp:location-eq, r=dtolnay

Derive common traits for panic::Location.

Now that `#[track_caller]` is on track to stabilize, one of the roughest edges of working with it is the fact that you can't do much with `Location` except turn it back into a `(&str, u32, u32)`. Which makes sense because the type was defined around the panic machinery originally passing around that tuple (it has the same layout as Location even).

This PR derives common traits for the type in accordance with the [API guidelines](https://rust-lang.github.io/api-guidelines/interoperability.html#types-eagerly-implement-common-traits-c-common-traits) (those apply to core, right?).

There's a risk here, e.g. if we ever change the representation of `Location` in a way that makes it harder to implement `Ord`, we might not be able to make that change in a backwards-compatible way. I don't think there's any other compatibility hazard here, as the only changes we currently imagine for the type are to add end fields.

cc @rust-lang/libs
src/libcore/panic.rs