run-make-support: add helpers for fs operations #125728
Labels
A-run-make
Area: port run-make Makefiles to rmake.rs
A-testsuite
Area: The testsuite used to check the correctness of rustc
C-cleanup
Category: PRs that clean code up or issues documenting cleanup.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
jieyouxu
added
C-cleanup
rustbot
added
the
needs-triage
jieyouxu
removed
the
needs-triage
|
Basically we want the support library to provide APIs almost like https://docs.rs/fs-err/latest/fs_err/ except panic-on-failure with good error messages instead of returning a |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 6, 2024
…r=jieyouxu run-make-support: add helpers for `tmp_dir().join()` and `fs` operations Suggested by rust-lang#125728. The point of this wrapper is to stop silent fails caused by forgetting to `unwrap` `fs` functions. However, functions like `fs::read` which return something and get stored in a variable should cause a failure on their own if they are not unwrapped (as the `Result` will be stored in the variable, and something will be done on that `Result` that should have been done to its contents). Is it still pertinent to wrap `fs::read_to_string`, `fs::metadata` and so on? try-job: x86_64-msvc
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 6, 2024
…r=<try> run-make-support: add helpers for `tmp_dir().join()` and `fs` operations Suggested by rust-lang#125728. The point of this wrapper is to stop silent fails caused by forgetting to `unwrap` `fs` functions. However, functions like `fs::read` which return something and get stored in a variable should cause a failure on their own if they are not unwrapped (as the `Result` will be stored in the variable, and something will be done on that `Result` that should have been done to its contents). Is it still pertinent to wrap `fs::read_to_string`, `fs::metadata` and so on? try-job: x86_64-msvc try-job: i686-mingw
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 6, 2024
…r=<try> run-make-support: add helpers for `tmp_dir().join()` and `fs` operations Suggested by rust-lang#125728. The point of this wrapper is to stop silent fails caused by forgetting to `unwrap` `fs` functions. However, functions like `fs::read` which return something and get stored in a variable should cause a failure on their own if they are not unwrapped (as the `Result` will be stored in the variable, and something will be done on that `Result` that should have been done to its contents). Is it still pertinent to wrap `fs::read_to_string`, `fs::metadata` and so on? try-job: x86_64-msvc try-job: i686-mingw
jieyouxu
changed the title
tmp_dir().join() and fs operations
github-project-automation
bot
moved this from In progress
to Done
in Oxidizing run-make tests
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Jun 13, 2024
run-make-support: add wrapper for `fs` operations Suggested by #125728. The point of this wrapper is to stop silent fails caused by forgetting to `unwrap` `fs` functions. However, functions like `fs::read` which return something and get stored in a variable should cause a failure on their own if they are not unwrapped (as the `Result` will be stored in the variable, and something will be done on that `Result` that should have been done to its contents). Is it still pertinent to wrap `fs::read_to_string`, `fs::metadata` and so on? Closes: rust-lang/rust#125728 try-job: x86_64-msvc try-job: i686-mingw
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Noticed in #125683 (comment), we should add helpers for:
std::fs::remove_file(path)withrun_make_support::fs::remove_file(path)but on panic shows thepathwe're trying to remove, so the test writer doesn't forget to check the result of fs operations.cc @Oneirical in case you want to work on this.
UPDATE: we reworked rmake.rs tests to not run in the test sources directory so
tmp_dir().join()is no longer relevant.The text was updated successfully, but these errors were encountered: