Derive common traits for panic::Location.

[anp]

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 (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

[rust-highfive]

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

[dtolnay]

These all seem fine to me. @rust-lang/libs: this adds the following impls for https://doc.rust-lang.org/nightly/std/panic/struct.Location.html:

• Copy
• Clone
• Eq
• Hash
• Ord
• PartialEq
• PartialOrd

@rfcbot fcp merge

Some notes:

• PartialOrd is based on comparing file, line, column in that order.

• PartialEq is equivalent to what you would get by calling file(), line(), column() and comparing the resulting &str, u32, u32. It is possible for the same location on the filesystem to have different file() in different places and thus compare unequal to itself, but this should be unusual. Example:

  // src/main.rs
  
  #![feature(track_caller)]
  
  #[path = "module.rs"]
  mod a;
  
  #[path = "../src/module.rs"]
  mod b;
  
  fn main() {
      println!("{}", a::get().file());
      println!("{}", b::get().file());
  }

  // src/module.rs
  
  use std::panic::Location;
  
  pub fn get() -> &'static Location<'static> {
      f()
  }
  
  #[track_caller]
  fn f() -> &'static Location<'static> {
      Location::caller()
  }

  src/module.rs
  src/../src/module.rs

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @SimonSapin
• @dtolnay
• @sfackler
• @withoutboats

Concerns:

• file ordering resolved by Derive common traits for panic::Location. #73583 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[Aaron1011]

Since the fields of Location are private, I think we should explicitly document the behavior of PartialOrd.

[anp]

Makes sense to me. Sounds like it may be worth adding tests for PartialEq and PartialOrd behavior.

[SimonSapin]

@rfcbot concern file ordering

In Location::ord (and partial_ord), should the file component be compared with Path::ord (component-wise) instead of str::ord? I think it would make more sense in the "happy" case, but Path is platform-specific and when cross compiling Location::file is meaningful for the host platform, not the target platform.

[anp]

Hm, that’s an interesting subtlety. Two thoughts:

1. the point you make about Path vs str is valid but the host/target mismatch seems like a dealbreaker
2. Ord is IMO the least valuable impl of those in this PR, and I included it for completeness based on the API guidelines

Thoughts on removing PartialOrd/Ord from this patch?

[SimonSapin]

I agree that "just" using Path::ord doesn’t work because of cross-compilation. We don’t have library support for host-platform paths separately from target-platform paths, and this doesn’t seem worth adding it.

Dropping these impls certainly resolves the issue and unblocks the rest of the PR, and we can always discuss separately adding them later.

That said I can live with using str::ord, we can mention this behavior in docs and users can access components and do something else if they need. I filed a concern so this gets discussed, but I’ll mark it resolved if others think this is the way to go.

[anp]

OK, I've added some documentation to address the comments here. If having this all documented makes it clear we should remove PartialOrd, let me know, otherwise I'm eager for feedback on the wording.

[SimonSapin]

This shows an example of Path ordering (which compares component-wise) being different from string ordering:

use std::path::Path;
pub fn main() {
    dbg!("foo-bar" < "foo/bar");
    dbg!(Path::new("foo-bar") < Path::new("foo/bar"));
    dbg!(vec!["foo-bar"] < vec!["foo", "bar"]);
}

(Playground)

[src/main.rs:3] "foo-bar" < "foo/bar" = true
[src/main.rs:4] Path::new("foo-bar") < Path::new("foo/bar") = false
[src/main.rs:5] vec!["foo-bar"] < vec!["foo", "bar"] = false

I couldn’t find examples other than where a path component on one side is a prefix of the same-position component on the other side, and the next character in the longer component is ordered before the path separator.

The only characters before / (the path separator on Unix) in ASCII are not allowed in a Rust identifier, so having them in a Rust source file path would require include!("…") or #[path = "…"] mod foo;. (On Windows the default separator is \, which sorts after digits and upper-case letter in ASCII.)

It looks like having a different ordering would be rather uncommon, so I think we can live with the slightly-incorrect one.

@rfcbot resolve file ordering

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[dtolnay]

Thanks for the new docs!

[dtolnay]

@bors r+

[bors]

📌 Commit 416dc4b has been approved by dtolnay

[bors]

⌛ Testing commit 416dc4b with merge 9be8ffc...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: dtolnay
Pushing 9be8ffc to master...