-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Migrate incr-add-rust-src-component
to rmake
#134656
Migrate incr-add-rust-src-component
to rmake
#134656
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
6e2f793
to
b9f4dd2
Compare
This comment has been minimized.
This comment has been minimized.
b9f4dd2
to
c6931e4
Compare
c6931e4
to
b334ba5
Compare
@bors try |
…omponent, r=<try> Migrate `incr-add-rust-src-component` to rmake **BLOCKED: this PR depends on rust-lang#134659** **TODO: actually write some useful PR description** r? `@ghost` try-job: i686-msvc try-job: x86_64-mingw-1 try-job: x86_64-msvc try-job: aarch64-apple
This comment has been minimized.
This comment has been minimized.
b334ba5
to
41b2c3d
Compare
This comment was marked as off-topic.
This comment was marked as off-topic.
@bors try |
…omponent, r=<try> Migrate `incr-add-rust-src-component` to rmake **BLOCKED: this PR depends on rust-lang#134659** **TODO: actually write some useful PR description** r? `@ghost` try-job: i686-msvc try-job: x86_64-mingw-1 try-job: x86_64-msvc try-job: aarch64-apple
☀️ Try build successful - checks-actions |
…Denton test-infra: improve compiletest and run-make-support symlink handling I was trying to implement rust-lang#134656 to port `tests/run-make/incr-add-rust-src-component.rs`, but found some blockers related to symlink handling, so in this PR I tried to resolve them by improving symlink handling in compiletest and run-make-support (particularly for native windows msvc environment). Key changes: - I needed to copy symlinks (duplicate a symlink pointing to the same file), so I pulled out the copy symlink logic and re-exposed it as `run_make_support::rfs::copy_symlink`. This helper correctly accounts for the Windows symlink-to-file vs symlink-to-dir distinction (hereafter "Windows symlinks") when copying symlinks. - `recursive_remove`: - I needed a way to remove symlinks themselves (no symlink traversal). `std::fs::remove_dir_all` handles them, but only if the root path is a directory. So I wrapped `std::fs::remove_dir_all` to also handle when the root path is a non-directory entity (e.g. file or symlink). Again, this properly accounts for Windows symlinks. - I wanted to use this for both compiletest and run-make-support, so I put the implementation and accompanying tests in `build_helper`. - In this sense, it's a reland of rust-lang#129302 with proper test coverage. - It's a thin wrapper around `std::fs::remove_dir_all` (`remove_dir_all` correctly handles read-only entries on Windows). The helper has additional permission-setting logic for when the root path is a non-dir entry on Windows to handle read-only non-dir entry. Fixes rust-lang#126334.
Rollup merge of rust-lang#134659 - jieyouxu:recursive-remove, r=ChrisDenton test-infra: improve compiletest and run-make-support symlink handling I was trying to implement rust-lang#134656 to port `tests/run-make/incr-add-rust-src-component.rs`, but found some blockers related to symlink handling, so in this PR I tried to resolve them by improving symlink handling in compiletest and run-make-support (particularly for native windows msvc environment). Key changes: - I needed to copy symlinks (duplicate a symlink pointing to the same file), so I pulled out the copy symlink logic and re-exposed it as `run_make_support::rfs::copy_symlink`. This helper correctly accounts for the Windows symlink-to-file vs symlink-to-dir distinction (hereafter "Windows symlinks") when copying symlinks. - `recursive_remove`: - I needed a way to remove symlinks themselves (no symlink traversal). `std::fs::remove_dir_all` handles them, but only if the root path is a directory. So I wrapped `std::fs::remove_dir_all` to also handle when the root path is a non-directory entity (e.g. file or symlink). Again, this properly accounts for Windows symlinks. - I wanted to use this for both compiletest and run-make-support, so I put the implementation and accompanying tests in `build_helper`. - In this sense, it's a reland of rust-lang#129302 with proper test coverage. - It's a thin wrapper around `std::fs::remove_dir_all` (`remove_dir_all` correctly handles read-only entries on Windows). The helper has additional permission-setting logic for when the root path is a non-dir entry on Windows to handle read-only non-dir entry. Fixes rust-lang#126334.
The Makefile version seems to contain a bug. Over the years, the directory structure of the `rust-src` component changed as the source tree directory structure changed. `libstd` is no longer a thing directly under `root/lib/rustlib/src/rust/src/`, it is moved to `root/lib/rustlib/src/rust/library/std`. Co-authored-by: Oneirical <[email protected]>
41b2c3d
to
7ee5204
Compare
//! Regression test for rust-lang/rust#70924. Check that if we add the `rust-src` component in | ||
//! between two incremental compiles, that the compiler doesn't ICE on the second invocation. | ||
//! | ||
//! This test uses symbolic links to save testing time. | ||
//! | ||
//! The way this test works is that, for every prefix in `root/lib/rustlib/src`, link all of prefix | ||
//! parent content, then remove the prefix, then loop on the next prefix. This way, we basically | ||
//! create a copy of the context around `root/lib/rustlib/src`, and can freely add/remove the src | ||
//! component itself. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: ... is this test actually testing what it thinks it's testing? Be it the original Makefile
version or this version...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so... in either case, your translation appears to preserve the intended behavior of the test (but perhaps that behavior itself isn't entirely correct?)
# This test uses `ln -s` rather than copying to save testing time, but its | ||
# usage doesn't work on windows. So ignore windows. | ||
|
||
# ignore-windows |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remark: by usage of pure rust test file, we're able to expand the test coverage of this to Windows as well. The symlink handling was fixed and improved in #134659.
//! Regression test for rust-lang/rust#70924. Check that if we add the `rust-src` component in | ||
//! between two incremental compiles, that the compiler doesn't ICE on the second invocation. | ||
//! | ||
//! This test uses symbolic links to save testing time. | ||
//! | ||
//! The way this test works is that, for every prefix in `root/lib/rustlib/src`, link all of prefix | ||
//! parent content, then remove the prefix, then loop on the next prefix. This way, we basically | ||
//! create a copy of the context around `root/lib/rustlib/src`, and can freely add/remove the src | ||
//! component itself. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so... in either case, your translation appears to preserve the intended behavior of the test (but perhaps that behavior itself isn't entirely correct?)
@bors r+ rollup |
…llaumeGomez Rollup of 4 pull requests Successful merges: - rust-lang#134656 (Migrate `incr-add-rust-src-component` to rmake) - rust-lang#134664 (Account for removal of multiline span in suggestion) - rust-lang#134772 (Improve/cleanup rustdoc code) - rust-lang#134781 (Add more `begin_panic` normalizations to panic backtrace tests) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#134656 - jieyouxu:migrate-incr-add-rust-src-component, r=wesleywiser Migrate `incr-add-rust-src-component` to rmake This PR partially supersedes rust-lang#128562, and ports the Makefile-based `tests/run-make/incr-add-rust-src-component` to use rmake.rs infra. Part of rust-lang#121876. This run-make test is a regression test for rust-lang#70924. It (tries to) checks that if we add the `rust-src` component in between two incremental compiles, that the compiler doesn't ICE on the second invocation. - Original issue:rust-lang#70924 - Fix PR: rust-lang#72767 - PR adding this regression test: rust-lang#72952 However, the Makefile version of this used `$SYSROOT/lib/rustlib/src/rust/src/libstd/lib.rs`, but that actually got moved around and reorganized over the years. As of Dec 2024, the `rust-src` component is more like (specific for our purposes): ``` $SYSROOT/lib/rustlib/src/rust/ library/std/src/lib.rs src/ ``` However, this run-make test is ancient and it exercises incr-comp system logic. I'm not sure if this test would actually catch the original regression. This PR was co-authored with `@Oneirical.` r? incremental try-job: i686-msvc try-job: x86_64-mingw-1 try-job: x86_64-msvc try-job: aarch64-apple
…-component, r=wesleywiser Migrate `incr-add-rust-src-component` to rmake This PR partially supersedes rust-lang#128562, and ports the Makefile-based `tests/run-make/incr-add-rust-src-component` to use rmake.rs infra. Part of rust-lang#121876. This run-make test is a regression test for rust-lang#70924. It (tries to) checks that if we add the `rust-src` component in between two incremental compiles, that the compiler doesn't ICE on the second invocation. - Original issue:rust-lang#70924 - Fix PR: rust-lang#72767 - PR adding this regression test: rust-lang#72952 However, the Makefile version of this used `$SYSROOT/lib/rustlib/src/rust/src/libstd/lib.rs`, but that actually got moved around and reorganized over the years. As of Dec 2024, the `rust-src` component is more like (specific for our purposes): ``` $SYSROOT/lib/rustlib/src/rust/ library/std/src/lib.rs src/ ``` However, this run-make test is ancient and it exercises incr-comp system logic. I'm not sure if this test would actually catch the original regression. This PR was co-authored with `@Oneirical.` r? incremental try-job: i686-msvc try-job: x86_64-mingw-1 try-job: x86_64-msvc try-job: aarch64-apple
…llaumeGomez Rollup of 4 pull requests Successful merges: - rust-lang#134656 (Migrate `incr-add-rust-src-component` to rmake) - rust-lang#134664 (Account for removal of multiline span in suggestion) - rust-lang#134772 (Improve/cleanup rustdoc code) - rust-lang#134781 (Add more `begin_panic` normalizations to panic backtrace tests) r? `@ghost` `@rustbot` modify labels: rollup
This PR partially supersedes #128562, and ports the Makefile-based
tests/run-make/incr-add-rust-src-component
to use rmake.rs infra.Part of #121876.
This run-make test is a regression test for #70924. It (tries to) checks that if we add the
rust-src
component in between two incremental compiles, that the compiler doesn't ICE on the second invocation.SourceFile
in new context' #70924However, the Makefile version of this used
$SYSROOT/lib/rustlib/src/rust/src/libstd/lib.rs
, but that actually got moved around and reorganized over the years. As of Dec 2024, therust-src
component is more like (specific for our purposes):However, this run-make test is ancient and it exercises incr-comp system logic. I'm not sure if this test would actually catch the original regression.
This PR was co-authored with @Oneirical.
r? incremental
try-job: i686-msvc
try-job: x86_64-mingw-1
try-job: x86_64-msvc
try-job: aarch64-apple