Add #[repr(transparent)] to Path & PathBuf

[jhpratt]

Given the vast number of impls on these two structs, it would be nearly
impossible to have any other internal representation without removing
any of these.

Resolves #72838.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @hanna-kruppe (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[Dylan-DPC-zz]

r? @dtolnay

[dtolnay]

Based on #72838 (comment) it sounds like this is motivated by wanting to do unsafe { mem::transmute::<&PathBuf, &OsString>(pathbuf) }.capacity() (and similar).

If so, I would prefer not to make this change. Note that repr(transparent) is not the same as permission to inspect or manipulate the internal representation of a type. That permission only exists if the field is also exposed as pub. So I believe this change doesn't make what you want to do any more correct than before.

[jhpratt]

Understandable. Question time, though. Is there any better way to do what I want? The internal details are unstable, although I don't believe it would make sense to be implemented any other way at this point. A read-only field would be ideal, but that's not a thing in Rust proper.

[dtolnay]

A way to e.g. read the capacity (or s/capacity/some_future_api/) of the OsString inside of PathBuf without PathBuf exposing the OsString or the capacity publicly? I don't know of a way but you could bring it up in #t-libs on zulip. You can transmute anyway but the correctness of that would be between you and the users of your crate.