Stop implementing std's MetadataExt
#342
Comments
|
Since the cap-std 1.0 ➡️ 2.0 bump I did ostreedev/ostree#3027 fixes the most painful thing to bump from my PoV. So don't let me stand in the way of any Rust improvements! |
sunfishcode
added a commit
that referenced
this issue
Jan 3, 2024
…xt`. Define our own copy of `MetadataExt` and `PermissionsExt` and change the code to use them instead of `std::os::*::fs::MetadataExt` and `std::os::*::fs::PermissionsExt'. In general, we should be moving away from using std's `Ext` traits like this, as they weren't meant to be used in this way. Fixes #342.
sunfishcode
added a commit
that referenced
this issue
Jan 10, 2024
…xt`. (#343) * Use custom traits instead of libstd's `MetadataExt` and `PermissionsExt`. Define our own copy of `MetadataExt` and `PermissionsExt` and change the code to use them instead of `std::os::*::fs::MetadataExt` and `std::os::*::fs::PermissionsExt'. In general, we should be moving away from using std's `Ext` traits like this, as they weren't meant to be used in this way. Fixes #342. * Have cap-std re-export the new traits, and update tests. * Update the build.rs scripts to fix Rust feature detection.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Rust is looking to seal
std::os::unix::fs::MetadataExt:rust-lang/rust#118916
As in #271 (which was before cap-std 1.0), cap-std can switch to defining its own copies of these traits. And since cap-std seems to be the only crate in the ecosystem that is affected, it should probably do this, to unblock std evolution.
However, this is a semver-incompatible change, so it'll require bumping cap-std to 3.0.
@cgwalters, who I know is particularly impacted by semver bumps
The text was updated successfully, but these errors were encountered: