Add `Path::has_trailing_sep` and related methods #142506

clarfonthey · 2025-06-14T14:17:56Z

Tracking issue: #142503

Notable differences from ACP:

trim_trailing_sep was added to Path since it felt reasonable to ensure that the inverse operation was available.
Per suggestion of @kennytm, added push_trailing_sep and pop_trailing_sep to PathBuf in addition to set_trailing_sep.

This also updates some of the docs on various Path methods to use the term "trailing separator" instead of "trailing slash" for consistency.

rustbot · 2025-06-14T14:17:59Z

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

clarfonthey · 2025-06-15T18:23:28Z

@rustbot author

rustbot · 2025-06-15T18:23:32Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

clarfonthey · 2025-06-29T17:27:39Z

Now that I know the workaround for the ./x test library/std, this should be good. But I'll wait until the tests pass (I'm only running on Linux atm) before I mark as ready.

There are a few edge cases, namely removing the trailing separator from /.

clarfonthey · 2025-06-29T22:32:30Z

@rustbot ready

bors · 2025-08-13T11:25:19Z

☔ The latest upstream changes (presumably #145334) made this pull request unmergeable. Please resolve the merge conflicts.

joboet · 2025-08-13T15:59:00Z

library/std/src/path.rs

+    /// assert_eq!(Path::new("dir/").trim_trailing_sep().as_os_str(), OsStr::new("dir"));
+    /// assert_eq!(Path::new("dir").trim_trailing_sep().as_os_str(), OsStr::new("dir"));
+    /// assert_eq!(Path::new("/").trim_trailing_sep().as_os_str(), OsStr::new("/"));
+    /// assert_eq!(Path::new("//").trim_trailing_sep().as_os_str(), OsStr::new("//"));


Is this correct? I would have thought that since // is the same as /, this would trim // to / (but feel free to correct me).

The idea here is that removing any number of /s would not affect the final path, and so, the path is left as-is. Essentially, any sequence of separators is treated as a single separator for the logic.

I could change it so that it returns / here but it felt better to be conservative: the logic is that trailing separators are removed if doing so would result in the same path without a trailing separator. Since there will always be trailing separators here, it doesn't make a difference to remove any. If your goal is "cleaning up" the path, then normalize and normalize_lexically exist instead.

Also another way to word this: x.trim_trailing_sep().as_os_str() == x.as_os_str() and x.trim_trailing_sep().has_trailing_sep() are equivalent.

(Note that the as_os_str is required since the trailing separator is ignored when comparing paths.)

This makes sense to me, but I'll ask for libs-api feedback just in case.

rustbot · 2025-08-21T00:43:20Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

rustbot assigned joboet Jun 14, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 14, 2025

clarfonthey mentioned this pull request Jun 14, 2025

Tracking Issue for path_trailing_sep #142503

Open

4 tasks