std: Add more accessors for Metadata on Windows#62980
Merged
bors merged 1 commit intorust-lang:masterfrom Jul 26, 2019
Merged
Conversation
Contributor
|
r? @bluss (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
Member
Author
|
r? @sfackler |
Member
|
r=me with a tracking issue filled out |
Collaborator
|
☔ The latest upstream changes (presumably #60260) made this pull request unmergeable. Please resolve the merge conflicts. |
Contributor
|
@alexcrichton I thought about the change once more: why do make a refactor and radically change the definition of This solution has the upside of not having to pattern match during runtime - you could just put the |
This commit adds accessors for more fields in `fs::Metadata` on Windows which weren't previously exposed. There's two sources of `fs::Metadata` on Windows currently, one from `DirEntry` and one from a file itself. These two sources of information don't actually have the same set of fields exposed in their stat information, however. To handle this the platform-specific accessors of Windows-specific information all return `Option` to return `None` in the case a metadata comes from a `DirEntry`, but they're guaranteed to return `Some` if it comes from a file itself. This is motivated by some changes in CraneStation/wasi-common#42, and I'm curious how others feel about this platform-specific functionality!
alexcrichton
force-pushed
the
windows-metadata
branch
from
31d7022 to
c69f367
Compare
Member
Author
|
@marmistrz I generally personally prefer to keep the original structures around for as long as possible, but the recent addition of UWP made that untenable anyway, so I went ahead and did what you're thinking anyway @bors: r=sfackler |
Collaborator
|
📌 Commit c69f367 has been approved by |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jul 26, 2019
…ackler std: Add more accessors for `Metadata` on Windows This commit adds accessors for more fields in `fs::Metadata` on Windows which weren't previously exposed. There's two sources of `fs::Metadata` on Windows currently, one from `DirEntry` and one from a file itself. These two sources of information don't actually have the same set of fields exposed in their stat information, however. To handle this the platform-specific accessors of Windows-specific information all return `Option` to return `None` in the case a metadata comes from a `DirEntry`, but they're guaranteed to return `Some` if it comes from a file itself. This is motivated by some changes in CraneStation/wasi-common#42, and I'm curious how others feel about this platform-specific functionality!
bors
added a commit
that referenced
this pull request
Jul 26, 2019
Rollup of 22 pull requests Successful merges: - #62084 (allow clippy::unreadable_literal in unicode tables) - #62120 (Add missing type links in documentation) - #62310 (Add missing doc links in boxed module) - #62421 (Introduce `as_deref` to Option) - #62583 (Implement Unpin for all raw pointers) - #62692 (rustc: precompute the largest Niche and store it in LayoutDetails.) - #62801 (Remove support for -Zlower-128bit-ops) - #62828 (Remove vector fadd/fmul reduction workarounds) - #62862 (code cleanup) - #62904 (Disable d32 on armv6 hf targets) - #62907 (Initialize the MSP430 AsmParser) - #62956 (Implement slow-path for FirstSets::first) - #62963 (Allow lexer to recover from some homoglyphs) - #62964 (clarify and unify some type test names) - #62970 (ci: gate toolstate repo pushes on the TOOLSTATE_PUBLISH envvar) - #62980 (std: Add more accessors for `Metadata` on Windows) - #62983 (Remove needless indirection through Rc) - #62985 (librustc_errors: Support ui-testing flag in annotate-snippet emitter) - #63002 (error_index_generator should output stdout/stderr when it panics.) - #63004 (Add test for issue-54062) - #63007 (ci: debug network failures while downloading awscli from PyPI) - #63009 (Remove redundant `mut` from variable declaration.) Failed merges: r? @ghost
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This commit adds accessors for more fields in
fs::Metadataon Windowswhich weren't previously exposed. There's two sources of
fs::Metadataon Windows currently, one from
DirEntryand one from a file itself.These two sources of information don't actually have the same set of
fields exposed in their stat information, however. To handle this the
platform-specific accessors of Windows-specific information all return
Optionto returnNonein the case a metadata comes from aDirEntry, but they're guaranteed to returnSomeif it comes from afile itself.
This is motivated by some changes in CraneStation/wasi-common#42, and
I'm curious how others feel about this platform-specific functionality!