run_make_support: rectify symlink handling #130427
Merged
Conversation
This file contains 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
rustbot
added
A-run-make
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 16, 2024
run_make_support: rectify symlink handling Avoid confusing Unix symlinks and Windows symlinks, and since their semantics are quite different we should avoid trying to make it to automagic in how symlinks are created and deleted. Notably, the tests should reflect what type of symlinks are to be created to match what std does to make it less surprising for test readers. r? `@ghost` try-job: x86_64-msvc try-job: aarch64-apple
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
bors
added
S-waiting-on-author
jieyouxu
force-pushed
the
rmake-symlink
branch
from
1fd1378 to
49d4c6b
Compare
Kobzol
reviewed
Sep 16, 2024
| } | ||
| #[cfg(windows)] | ||
| { | ||
| rfs::windows::symlink_file( |
There was a problem hiding this comment.
This seems quite cumbersome, error-prone and hard to read. Can't we create more precise variants of the symlink functions (symlink_file, symlink_dir - or whatever other versions needed) and then let each runmake test decide which exact variant it needs, and handle the implementation difference itself in rfs?
The test will probably always do the same thing on Unix and Windows; we just need to force the test to be more explicit in what kind of symlink it needs.
Like this:
// runmake test
rfs::symlink_file("a", "b");
rfs::symlink_dir("x", "y");
// rfs
unix::symlink_file => symlink
unix::symlink_dir => symlink
windows::symlink_file => symlink_file
windows::symlink_dir => symlink_dirThere was a problem hiding this comment.
Yeah that seems reasonable. I'll change this tomorrow.
There was a problem hiding this comment.
(I lied I changed this today)
jieyouxu
force-pushed
the
rmake-symlink
branch
from
49d4c6b to
a46d4bb
Compare
|
Should be ready for review now. r? @Kobzol since you're already looking at it |
jieyouxu
force-pushed
the
rmake-symlink
branch
from
a46d4bb to
555a732
Compare
ChrisDenton
reviewed
Sep 16, 2024
Avoid confusing Unix symlinks and Windows symlinks, and since their semantics are quite different we should avoid trying to make it to automagic in how symlinks are created and deleted. Notably, the tests should reflect what type of symlinks are to be created to match what std does to make it less surprising for test readers.
jieyouxu
force-pushed
the
rmake-symlink
branch
from
555a732 to
e81c05e
Compare
Kobzol
reviewed
Sep 16, 2024
|
|
jieyouxu
force-pushed
the
rmake-symlink
branch
from
e81c05e to
7d76428
Compare
|
Fixed the tests to use |
|
Good :) You can r=me once CI is green. |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 17, 2024
…iaskrgr Rollup of 4 pull requests Successful merges: - rust-lang#130380 (coverage: Clarify some parts of coverage counter creation) - rust-lang#130427 (run_make_support: rectify symlink handling) - rust-lang#130447 (rustc_llvm: update for llvm/llvm-project@2ae968a0d9fb61606b020e898d88…) - rust-lang#130448 (fix: Remove duplicate `LazyLock` example.) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 17, 2024
Rollup merge of rust-lang#130427 - jieyouxu:rmake-symlink, r=Kobzol run_make_support: rectify symlink handling Avoid confusing Unix symlinks and Windows symlinks. Since their semantics are quite different, we should avoid trying to make it automagic in how symlinks are created and deleted. Notably, the tests should reflect what type of symlinks are to be created to match what std does to make it less surprising for test readers.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Avoid confusing Unix symlinks and Windows symlinks. Since their
semantics are quite different, we should avoid trying to make it
automagic in how symlinks are created and deleted. Notably, the tests
should reflect what type of symlinks are to be created to match what std
does to make it less surprising for test readers.