std: Stabilize a number of new fs features #25844

alexcrichton · 2015-05-27T23:47:09Z

This commit stabilizes the following APIs, slating them all to be cherry-picked
into the 1.1 release.

fs::FileType (and transitively the derived trait implementations)
fs::Metadata::file_type
fs::FileType::is_dir
fs::FileType::is_file
fs::FileType::is_symlink
fs::DirEntry::metadata
fs::DirEntry::file_type
fs::DirEntry::file_name
fs::set_permissions
fs::symlink_metadata
os::raw::{self, *}
os::{android, bitrig, linux, ...}::raw::{self, *}
os::{android, bitrig, linux, ...}::fs::MetadataExt
os::{android, bitrig, linux, ...}::fs::MetadataExt::as_raw_stat
os::unix::fs::PermissionsExt
os::unix::fs::PermissionsExt::mode
os::unix::fs::PermissionsExt::set_mode
os::unix::fs::PermissionsExt::from_mode
os::unix::fs::OpenOptionsExt
os::unix::fs::OpenOptionsExt::mode
os::unix::fs::DirEntryExt
os::unix::fs::DirEntryExt::ino
os::windows::fs::MetadataExt
os::windows::fs::MetadataExt::file_attributes
os::windows::fs::MetadataExt::creation_time
os::windows::fs::MetadataExt::last_access_time
os::windows::fs::MetadataExt::last_write_time
os::windows::fs::MetadataExt::file_size

The os::unix::fs::Metadata structure was also removed entirely, moving all of
its associated methods into the os::unix::fs::MetadataExt trait instead. The
methods are all marked as #[stable] still.

As some minor cleanup, some deprecated and unstable fs apis were also removed:

File::path
Metadata::accessed
Metadata::modified

Features that were explicitly left unstable include:

fs::WalkDir - the semantics of this were not considered in the recent fs
expansion RFC.
fs::DirBuilder - it's still not 100% clear if the naming is right here and if
the set of functionality exposed is appropriate.
fs::canonicalize - the implementation on Windows here is specifically in
question as it always returns a verbatim path. Additionally the Unix
implementation is susceptible to buffer overflows on long paths unfortunately.
fs::PathExt - as this is just a convenience trait, it is not stabilized at
this time.
fs::set_file_times - this funciton is still waiting on a time abstraction.

rust-highfive · 2015-05-27T23:47:22Z

r? @huonw

(rust_highfive has picked a reviewer for you, use r? to override)

alexcrichton · 2015-05-27T23:47:28Z

r? @aturon

cc @rust-lang/libs

steveklabnik · 2015-05-27T23:50:11Z

Does this let Cargo build on stable? IIRC, it was only missing some FS labels.

I'm 👍 to backporting this to beta because it's 1.1. If it were 1.2, I'd say just wait.

alexcrichton · 2015-05-27T23:52:46Z

It does indeed! Cargo also needs the catch_panic feature to build 100% on stable, but it can just not use that feature of git2-rs for now and have panics turn into aborts (Cargo rarely panics anyway)

retep998 · 2015-05-28T00:23:32Z

With this winapi will be able to drop its dependence on libc!

BurntSushi · 2015-05-28T23:34:01Z

Yay! I think this also lets xsv compile on Rust stable too.

👍

alexcrichton · 2015-06-02T21:16:58Z

This PR is now entering the final comment period for stabilizing these APIs!

sfackler · 2015-06-04T02:53:03Z

Should os::windows::fs::MetadataExt::{creation_time, last_access_time, last_write_time} be left unstable until a suitable time type exists, or perhaps renamed in the same style as wait_timeout_ms?

alexcrichton · 2015-06-04T04:34:39Z

I personally view os::*::fs::MetadataExt as accessors of the raw underlying fields, so even if we had an abstraction for time I'd probably still opt to not return the abstraction but rather the u64 itself. There definitely does seem to be a use case, however, for a middle layer of abstraction sometimes, and this may not be the best way to draw the line in the end.

sfackler · 2015-06-04T14:13:39Z

Works for me.

bors · 2015-06-05T15:30:00Z

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

Stebalien · 2015-06-05T22:06:42Z

src/libstd/fs.rs

@@ -663,15 +623,17 @@ impl Permissions {
    }
 }

-#[unstable(feature = "file_type", reason = "recently added API")]
 impl FileType {


I probably missed the discussion but why is this not an (extensible) enum? This seems like a really good candidate. Yes, some of the variants won't make sense on certain platforms but I don't think that's really an issue (we'll just have extra variants) and being able to match on filetype would be really nice.

Variants:

enum FileType { // Common Directory, File, Symlink, // Windows Only ReparsePoint, // Unix Only CharDev, BlockDev, NamedPipe, Socket, #[doc(hidden)] __non_exhaustive }

We're currently not necessarily considering a hidden/unstable variant to be an "unstable enum", it was mostly just how ErrorKind worked out. The set of file types also varies quite a bit across platforms, and the extra types made somewhat more sense to provide through extension traits instead of via this enum.

Finally, using an opaque structure allows one day accessing the raw bits used to determine the file type which may contain some unknown information.

This actually makes it easier to write cross-platform code because the coder doesn't need to care about the platform: they just handle all cases on all platforms (when possible).

It's somewhat of a fine line between being able to write cross-platform code while still understand what is indeed cross platform. If we were to have an exhaustive enum which is the union of all file types on all platforms, it's suddenly not clear what file types come up on which platforms. Which is to say that it's not clear to me that having a union is indeed more cross platform as you're probably still going to have platform-specific code handling various file types on various platforms.

We're currently not necessarily considering a hidden/unstable variant to be an "unstable enum", it was mostly just how ErrorKind worked out.

Given that we're already doing this, I don't see why we shouldn't do it here.

The set of file types also varies quite a bit across platforms, and the extra types made somewhat more sense to provide through extension traits instead of via this enum.

The problem with extension traits is that they force the user to care about the platform. With an enum, I could write:

fn format_filetype(s: &mut String, entry: &DirEntry) { match entry.file_type() { File => s.push('f'), NamedPipe => s.push('p'), ReparsePoint => s.push('r'), Other => s.push('?'), // ... } }

With extension traits, I need one function per platform (each one importing a different extension trait). Extension traits are useful when some set of functionality is nonsensical on a platform but in this case, the extra file types make sense, they just aren't used.

Finally, using an opaque structure allows one day accessing the raw bits used to determine the file type which may contain some unknown information.

This unknown information is stored in the Metadata structure. Are you worried about unknown file types or something? Pretty much by definition, a file should only have one type so an enum should always be able to describe it.

Sorry, I'm not re-loading before posting... For now, I feel that the enum is small enough that this isn't really an issue however, I can see this becoming an issue in the future as more platforms are added and this enum grows. So I see your point.

alexcrichton · 2015-06-09T22:41:12Z

triage: beta-accepted

alexcrichton · 2015-06-10T00:01:46Z

re-r? @aturon

I've rebased and updated this PR to include a snippet in RELEASES.md to talk about the new features.

retep998 · 2015-06-10T00:24:56Z

src/libstd/os/raw.rs

-pub type c_float = f32;
-pub type c_double = f64;
+#[cfg(target_arch = "aarch64")]
+#[stable(feature = "raw_os", since = "1.0.0")] pub type c_char = u8;


Uh, shouldn't all these be stable for 1.1.0 and not 1.0.0?

Ah oops, thanks!

This commit stabilizes the following APIs, slating them all to be cherry-picked into the 1.1 release. * fs::FileType (and transitively the derived trait implementations) * fs::Metadata::file_type * fs::FileType::is_dir * fs::FileType::is_file * fs::FileType::is_symlink * fs::DirEntry::metadata * fs::DirEntry::file_type * fs::DirEntry::file_name * fs::set_permissions * fs::symlink_metadata * os::raw::{self, *} * os::{android, bitrig, linux, ...}::raw::{self, *} * os::{android, bitrig, linux, ...}::fs::MetadataExt * os::{android, bitrig, linux, ...}::fs::MetadataExt::as_raw_stat * os::unix::fs::PermissionsExt * os::unix::fs::PermissionsExt::mode * os::unix::fs::PermissionsExt::set_mode * os::unix::fs::PermissionsExt::from_mode * os::unix::fs::OpenOptionsExt * os::unix::fs::OpenOptionsExt::mode * os::unix::fs::DirEntryExt * os::unix::fs::DirEntryExt::ino * os::windows::fs::MetadataExt * os::windows::fs::MetadataExt::file_attributes * os::windows::fs::MetadataExt::creation_time * os::windows::fs::MetadataExt::last_access_time * os::windows::fs::MetadataExt::last_write_time * os::windows::fs::MetadataExt::file_size The `os::unix::fs::Metadata` structure was also removed entirely, moving all of its associated methods into the `os::unix::fs::MetadataExt` trait instead. The methods are all marked as `#[stable]` still. As some minor cleanup, some deprecated and unstable fs apis were also removed: * File::path * Metadata::accessed * Metadata::modified Features that were explicitly left unstable include: * fs::WalkDir - the semantics of this were not considered in the recent fs expansion RFC. * fs::DirBuilder - it's still not 100% clear if the naming is right here and if the set of functionality exposed is appropriate. * fs::canonicalize - the implementation on Windows here is specifically in question as it always returns a verbatim path. Additionally the Unix implementation is susceptible to buffer overflows on long paths unfortunately. * fs::PathExt - as this is just a convenience trait, it is not stabilized at this time. * fs::set_file_times - this funciton is still waiting on a time abstraction.

aturon · 2015-06-12T20:11:42Z

This has gone through FCP and been reviewed by the core team, and we're ready to land the stabilization!

@bors: r+

bors · 2015-06-12T20:11:43Z

📌 Commit ec68c4a has been approved by aturon

bors · 2015-06-12T21:31:38Z

⌛ Testing commit ec68c4a with merge 50ab23d...

This commit stabilizes the following APIs, slating them all to be cherry-picked into the 1.1 release. * fs::FileType (and transitively the derived trait implementations) * fs::Metadata::file_type * fs::FileType::is_dir * fs::FileType::is_file * fs::FileType::is_symlink * fs::DirEntry::metadata * fs::DirEntry::file_type * fs::DirEntry::file_name * fs::set_permissions * fs::symlink_metadata * os::raw::{self, *} * os::{android, bitrig, linux, ...}::raw::{self, *} * os::{android, bitrig, linux, ...}::fs::MetadataExt * os::{android, bitrig, linux, ...}::fs::MetadataExt::as_raw_stat * os::unix::fs::PermissionsExt * os::unix::fs::PermissionsExt::mode * os::unix::fs::PermissionsExt::set_mode * os::unix::fs::PermissionsExt::from_mode * os::unix::fs::OpenOptionsExt * os::unix::fs::OpenOptionsExt::mode * os::unix::fs::DirEntryExt * os::unix::fs::DirEntryExt::ino * os::windows::fs::MetadataExt * os::windows::fs::MetadataExt::file_attributes * os::windows::fs::MetadataExt::creation_time * os::windows::fs::MetadataExt::last_access_time * os::windows::fs::MetadataExt::last_write_time * os::windows::fs::MetadataExt::file_size The `os::unix::fs::Metadata` structure was also removed entirely, moving all of its associated methods into the `os::unix::fs::MetadataExt` trait instead. The methods are all marked as `#[stable]` still. As some minor cleanup, some deprecated and unstable fs apis were also removed: * File::path * Metadata::accessed * Metadata::modified Features that were explicitly left unstable include: * fs::WalkDir - the semantics of this were not considered in the recent fs expansion RFC. * fs::DirBuilder - it's still not 100% clear if the naming is right here and if the set of functionality exposed is appropriate. * fs::canonicalize - the implementation on Windows here is specifically in question as it always returns a verbatim path. Additionally the Unix implementation is susceptible to buffer overflows on long paths unfortunately. * fs::PathExt - as this is just a convenience trait, it is not stabilized at this time. * fs::set_file_times - this funciton is still waiting on a time abstraction.

bors · 2015-06-12T23:05:04Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt

rust-highfive assigned huonw May 27, 2015

rust-highfive assigned aturon and unassigned huonw May 27, 2015

alexcrichton added beta-nominated Nominated for backporting to the compiler in the beta channel. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels May 27, 2015

alexcrichton force-pushed the stabilize-fs-features branch 3 times, most recently from 1bd9143 to ab0e4d7 Compare May 28, 2015 21:14

willem66745 mentioned this pull request May 29, 2015

postponed: mtime based reload of config file willem66745/keeper-rust#1

Open

alexcrichton added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Jun 2, 2015

Stebalien reviewed Jun 5, 2015
View reviewed changes

BurntSushi mentioned this pull request Jun 8, 2015

Remake PollWatcher notify-rs/notify#12

Closed

alexcrichton added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Jun 9, 2015

alexcrichton force-pushed the stabilize-fs-features branch from ab0e4d7 to c72cf72 Compare June 10, 2015 00:01

retep998 reviewed Jun 10, 2015
View reviewed changes

alexcrichton force-pushed the stabilize-fs-features branch from c72cf72 to ec68c4a Compare June 10, 2015 00:44

bors merged commit ec68c4a into rust-lang:master Jun 12, 2015

This was referenced Jun 12, 2015

Break apart global unstable features #26192

Merged

Update authors and relnotes for 1.1 #26200

Merged

alexcrichton mentioned this pull request Jun 17, 2015

Backport accepted PRs to beta #26371

Merged

alexcrichton removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Jun 17, 2015

omasanori mentioned this pull request Jun 24, 2015

RELEASES.md lacks [fs-expand] #26537

Closed

alexcrichton deleted the stabilize-fs-features branch July 10, 2015 22:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

std: Stabilize a number of new fs features #25844

std: Stabilize a number of new fs features #25844

alexcrichton commented May 27, 2015

rust-highfive commented May 27, 2015

alexcrichton commented May 27, 2015

steveklabnik commented May 27, 2015

alexcrichton commented May 27, 2015

retep998 commented May 28, 2015

BurntSushi commented May 28, 2015

alexcrichton commented Jun 2, 2015

sfackler commented Jun 4, 2015

alexcrichton commented Jun 4, 2015

sfackler commented Jun 4, 2015

bors commented Jun 5, 2015

Stebalien Jun 5, 2015

Stebalien Jun 5, 2015

alexcrichton Jun 5, 2015

Stebalien Jun 5, 2015

alexcrichton Jun 5, 2015

Stebalien Jun 5, 2015

Stebalien Jun 6, 2015

alexcrichton commented Jun 9, 2015

alexcrichton commented Jun 10, 2015

retep998 Jun 10, 2015

alexcrichton Jun 10, 2015

aturon commented Jun 12, 2015

bors commented Jun 12, 2015

bors commented Jun 12, 2015

bors commented Jun 12, 2015

std: Stabilize a number of new fs features #25844

std: Stabilize a number of new fs features #25844

Conversation

alexcrichton commented May 27, 2015

rust-highfive commented May 27, 2015

alexcrichton commented May 27, 2015

steveklabnik commented May 27, 2015

alexcrichton commented May 27, 2015

retep998 commented May 28, 2015

BurntSushi commented May 28, 2015

alexcrichton commented Jun 2, 2015

sfackler commented Jun 4, 2015

alexcrichton commented Jun 4, 2015

sfackler commented Jun 4, 2015

bors commented Jun 5, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcrichton commented Jun 9, 2015

alexcrichton commented Jun 10, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aturon commented Jun 12, 2015

bors commented Jun 12, 2015

bors commented Jun 12, 2015

bors commented Jun 12, 2015