New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use top level `fs` functions where appropriate #56258

Merged
merged 1 commit into from Dec 8, 2018

Conversation

Projects
None yet
5 participants
@euclio
Contributor

euclio commented Nov 26, 2018

This commit replaces many usages of File::open and reading or writing
with fs::read_to_string, fs::read and fs::write. This reduces code
complexity, and will improve performance for most reads, since the
functions allocate the buffer to be the size of the file.

I believe that this commit will not impact behavior in any way, so some
matches will check the error kind in case the file was not valid UTF-8.
Some of these cases may not actually care about the error.

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Nov 26, 2018

r? @nikomatsakis

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

let stamp_contents = match fs::read(stamp) {
Ok(contents) => contents,
Err(ref err) if err.kind() == ErrorKind::InvalidData => {
panic!("could not read contents of stamp");

This comment has been minimized.

@Mark-Simulacrum

Mark-Simulacrum Nov 27, 2018

Member

Why would InvalidData come up? I could maybe see it if we were reading to string, but with just a Vec return value I don't quite see it -- and this does appear to be new code

This comment has been minimized.

@euclio

euclio Nov 27, 2018

Contributor

I was trying to keep the behavior that errors opening the file are ignored but errors reading the file panic. You're right that InvalidData won't come up when we're reading bytes -- it's probably best to just do something like let contents = fs::read(stamp).ok();?

EDIT: Pushed a commit fixing this.

let mut f = try_err!(File::open(&entry), &entry);
try_err!(f.read_to_end(&mut content), &entry);
let content = try_err!(fs::read(&entry), &entry);

This comment has been minimized.

@Mark-Simulacrum

Mark-Simulacrum Nov 27, 2018

Member

Technically I think this might be a change in performance so cc @rust-lang/rustdoc but I think the new behavior is better, not worse, since we'll allocate correctly versus just guessing.

Show resolved Hide resolved src/libsyntax/source_map.rs

@euclio euclio force-pushed the euclio:fs-read-write branch from 3bb2545 to 9bc4349 Nov 27, 2018

@Mark-Simulacrum

This comment has been minimized.

Member

Mark-Simulacrum commented Nov 27, 2018

If you could squash the commits here into one that'd be great; r=me modulo that

@euclio euclio force-pushed the euclio:fs-read-write branch from 9bc4349 to be89dff Nov 27, 2018

@euclio

This comment has been minimized.

Contributor

euclio commented Nov 27, 2018

Squashed.

@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented Nov 29, 2018

@bors r=Mark-Simulacrum

r? @Mark-Simulacrum

@bors

This comment has been minimized.

Contributor

bors commented Nov 29, 2018

📌 Commit be89dff has been approved by Mark-Simulacrum

pietroalbini added a commit to pietroalbini/rust that referenced this pull request Nov 29, 2018

Rollup merge of rust-lang#56258 - euclio:fs-read-write, r=Mark-Simula…
…crum

use top level `fs` functions where appropriate

This commit replaces many usages of `File::open` and reading or writing
with `fs::read_to_string`, `fs::read` and `fs::write`. This reduces code
complexity, and will improve performance for most reads, since the
functions allocate the buffer to be the size of the file.

I believe that this commit will not impact behavior in any way, so some
matches will check the error kind in case the file was not valid UTF-8.
Some of these cases may not actually care about the error.

bors added a commit that referenced this pull request Nov 30, 2018

Auto merge of #56353 - pietroalbini:rollup, r=pietroalbini
Rollup of 11 pull requests

Successful merges:

 - #55821 (Use sort_by_cached_key when the key function is not trivial/free)
 - #56014 (add test for issue #21335)
 - #56131 (Assorted tweaks)
 - #56165 (drop glue takes in mutable references, it should reflect that in its type)
 - #56205 (Fix ICE with feature self_struct_ctor)
 - #56216 (Add TryFrom<&[T]> for [T; $N] where T: Copy)
 - #56258 (use top level `fs` functions where appropriate)
 - #56268 (Reuse the `P` in `InvocationCollector::fold_{,opt_}expr`.)
 - #56339 (Remove not used option)
 - #56341 (Rename conversion util; remove duplicate util in librustc_codegen_llvm.)
 - #56349 (rustc 1.30.0's linker flavor inference is a non-backwards compat change to -Clinker)

Failed merges:

 - #56285 (move stage0.txt to toplevel directory)

r? @ghost
@bors

This comment has been minimized.

Contributor

bors commented Nov 30, 2018

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

@euclio euclio force-pushed the euclio:fs-read-write branch from be89dff to d809d21 Dec 1, 2018

@euclio

This comment has been minimized.

Contributor

euclio commented Dec 1, 2018

Rebased.

@euclio

This comment has been minimized.

Contributor

euclio commented Dec 5, 2018

@Mark-Simulacrum

This comment has been minimized.

Member

Mark-Simulacrum commented Dec 5, 2018

@bors r+

@bors

This comment has been minimized.

Contributor

bors commented Dec 5, 2018

📌 Commit d809d21 has been approved by Mark-Simulacrum

pietroalbini added a commit to pietroalbini/rust that referenced this pull request Dec 5, 2018

Rollup merge of rust-lang#56258 - euclio:fs-read-write, r=Mark-Simula…
…crum

use top level `fs` functions where appropriate

This commit replaces many usages of `File::open` and reading or writing
with `fs::read_to_string`, `fs::read` and `fs::write`. This reduces code
complexity, and will improve performance for most reads, since the
functions allocate the buffer to be the size of the file.

I believe that this commit will not impact behavior in any way, so some
matches will check the error kind in case the file was not valid UTF-8.
Some of these cases may not actually care about the error.
@bors

This comment has been minimized.

Contributor

bors commented Dec 6, 2018

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

@euclio euclio force-pushed the euclio:fs-read-write branch from d809d21 to 4ed9da8 Dec 6, 2018

@euclio

This comment has been minimized.

Contributor

euclio commented Dec 6, 2018

Rebased again. Notably in the merge I tweaked the logic a bit to avoid a clone if the file doesn't contain UTF-8.

let (contents, bytes) = match String::from_utf8(bytes) {
Ok(s) => {
let bytes = s.as_bytes().to_owned();
(s, bytes)
},
Err(e) => (String::new(), e.into_bytes()),
};

@bors

This comment has been minimized.

Contributor

bors commented Dec 7, 2018

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

use top level `fs` functions where appropriate
This commit replaces many usages of `File::open` and reading or writing
with `fs::read_to_string`, `fs::read` and `fs::write`. This reduces code
complexity, and will improve performance for most reads, since the
functions allocate the buffer to be the size of the file.

I believe that this commit will not impact behavior in any way, so some
matches will check the error kind in case the file was not valid UTF-8.
Some of these cases may not actually care about the error.
@Mark-Simulacrum

This comment has been minimized.

Member

Mark-Simulacrum commented Dec 7, 2018

@bors delegate+

You should be able to re-approve from here once you've rebased.

@bors

This comment has been minimized.

Contributor

bors commented Dec 7, 2018

✌️ @euclio can now approve this pull request

@euclio euclio force-pushed the euclio:fs-read-write branch from 4ed9da8 to 2f62265 Dec 7, 2018

@euclio

This comment has been minimized.

Contributor

euclio commented Dec 7, 2018

Travis passed.

@bors r+

@bors

This comment has been minimized.

Contributor

bors commented Dec 7, 2018

📌 Commit 2f62265 has been approved by euclio

@bors

This comment has been minimized.

Contributor

bors commented Dec 7, 2018

⌛️ Testing commit 2f62265 with merge 0a77980...

bors added a commit that referenced this pull request Dec 7, 2018

Auto merge of #56258 - euclio:fs-read-write, r=euclio
use top level `fs` functions where appropriate

This commit replaces many usages of `File::open` and reading or writing
with `fs::read_to_string`, `fs::read` and `fs::write`. This reduces code
complexity, and will improve performance for most reads, since the
functions allocate the buffer to be the size of the file.

I believe that this commit will not impact behavior in any way, so some
matches will check the error kind in case the file was not valid UTF-8.
Some of these cases may not actually care about the error.
@bors

This comment has been minimized.

Contributor

bors commented Dec 8, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: euclio
Pushing 0a77980 to master...

@bors bors merged commit 2f62265 into rust-lang:master Dec 8, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

alexcrichton added a commit to alexcrichton/rust that referenced this pull request Dec 11, 2018

@euclio euclio deleted the euclio:fs-read-write branch Dec 11, 2018

bors added a commit that referenced this pull request Dec 11, 2018

Auto merge of #56703 - alexcrichton:fix-tools, r=Mark-Simulacrum
Fix build of the `build-manifest` tool

Accidentally broken in #56258!

bors added a commit that referenced this pull request Dec 11, 2018

Auto merge of #56703 - alexcrichton:fix-tools, r=Mark-Simulacrum
Fix build of the `build-manifest` tool

Accidentally broken in #56258!

euclio added a commit to euclio/rust that referenced this pull request Dec 14, 2018

rep-nop added a commit to rep-nop/rust that referenced this pull request Dec 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment