Require #[repr(C)] for RelativePath

[lo48576]

I heard that the code such as below is unsound (lead to undefined behaviour):

relative-path/src/lib.rs

Lines 271 to 280 in 49d76f3

	/// A borrowed, immutable relative path.
	pub struct RelativePath {
	inner: str,
	}
	impl RelativePath {
	/// Directly wraps a string slice as a `RelativePath` slice.
	pub fn new<S: AsRef<str> + ?Sized>(s: &S) -> &RelativePath {
	unsafe { mem::transmute(s.as_ref()) }
	}

RelativePath type should have #[repr(C)] (stable) or #[repr(transparent)] (unstable) to be safe.

This is because Rust doesn't guarantee that str and RelativePath have the same internal representations (and it will be guaranteed by #[repr(C)]).

For detail:

• OpaqueTypedefUnsized::from_* are unsound · Issue #1 · lo48576/opaque_typedef
• UncasedStr::new is undefined behavior · Issue #494 · SergioBenitez/Rocket

[udoprog]

Also: rust-lang/rust#45910

Yeah, I'm keeping an eye on the stabilization for #[repr(transparent)] for this. I guess we could consider using #[repr(C)] until then.

[udoprog]

🎉 #[repr(transparent)] is now in stable (1.28)!

[udoprog]

Fixed in 20d222a