make `OsString::new` and `PathBuf::new` unstably const
Since #129041, `String::into_bytes` is `const`, which allows making `OsString::new` and `PathBuf::new` unstably const now.
Not sure what the exact process for this is; does it need an ACP?
Path::with_extension: show that it adds an extension where one did no…
…t exist
I think the times I encountered this, I had to check first if files without extensions were added, since all examples only had files with existing extensions.
Also, this replaced example already has a similar example below.
Avoid redundant WTF-8 checks in `PathBuf`
Eliminate checks for WTF-8 boundaries in `PathBuf::set_extension` and `add_extension`, where joining WTF-8 surrogate halves is impossible. Don't convert the `str` to `OsStr`, because `OsString::push` specializes to skip the joining when given strings.
To assist in this, mark the internal methods `OsString::truncate` and `extend_from_slice` as `unsafe` to communicate their safety invariants better than with module privacy.
Similar to #137777.
cc `@joboet` `@ChrisDenton`
Eliminate checks for WTF-8 boundaries in `PathBuf::set_extension` and
`add_extension`, where joining WTF-8 surrogate halves is impossible.
Don't convert the `str` to `OsStr`, because `OsString::push` specializes
to skip the joining when given strings.
The extension is validated in `PathBuf::set_extension`, but not
`add_extension`. Fix that. Check for both / and \ path separators on
Windows, even when the path is verbatim, since this is logically like
`PathBuf::push` which normalizes separators (i.e., keeping the current
behavior).
I am working on fs support for UEFI [0], which similar to windows has prefix
components, but is not quite same as Windows. It also seems that Prefix
is tied closely to Windows and cannot really be extended [1].
This PR just tries to remove coupling between Prefix and absolute path
checking to allow platforms to provide there own implementation to check
if a path is absolute or not.
I am not sure if any platform other than windows currently uses Prefix,
so I have kept the path.prefix().is_some() check in most cases.
[0]: https://github.com/rust-lang/rust/pull/135368
[1]: https://github.com/rust-lang/rust/issues/52331#issuecomment-2492796137
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Since the stabilization in #127679 has reached stage0, 1.82-beta, we can
start using `&raw` freely, and even the soft-deprecated `ptr::addr_of!`
and `ptr::addr_of_mut!` can stop allowing the unstable feature.
I intentionally did not change any documentation or tests, but the rest
of those macro uses are all now using `&raw const` or `&raw mut` in the
standard library.
Improve std::Path's Hash quality by avoiding prefix collisions
This adds a bit rotation to the already existing state so that the same sequence of characters chunked at different offsets into separate path components results in different hashes.
The tests are from #127255Closes#127254
These changes bring it closer to other standard library documentation
and, in particular, `std::fs::canonicalize`, which it will often be
compared with.
* Add `# Platform-specific behavior` section, with content moved from
Examples section.
* Create `# Errors` section.
* Phrase error description to allow future platforms to have new
syntactic errors, rather than only emptiness.
* Add missing commas.
* Indent example code 4 spaces.
