-
Notifications
You must be signed in to change notification settings - Fork 474
Added Rust 1.62.0 #1427
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
Added Rust 1.62.0 #1427
Conversation
This is blocked by the following error on windows: https://buildkite.com/bazel/rules-rust-rustlang/builds/6678#0181b81d-22e9-42be-92fe-ec6401ed53a2 Input from anyone with any windows experience would be welcomed 🙏
|
7c22a98
to
5c18ea4
Compare
#1427 (comment) appeared to be a flaky failure on windows 😞 |
@illicitonion friendly ping 😅 |
I just spent the better part of my day hunting that flake, tl;dr I believe the issue comes from rust_doc_test overwriting the outputs of the underlying crate. I managed to consistently reproduce the failure with
Will send a PR tomorrow. |
This is supposed to fix the long standing Windows flakiness as described in #1427 (comment) Initially I thought it's an issue with `rustdoc_test`, however the actual issue is that `rust_binary` and its `rust_test` have the same crate name and generate the same intermediary `.o` files. For sandboxed builds this is not an issue, as the actions are isolated, however, we have a race condition in non-sandboxed builds (Windows): Let's consider the following build: ``` bazel build --spawn_strategy=standalone \ //test/unit/rustdoc:bin_with_transitive_proc_macro \ //test/unit/rustdoc:bin_with_transitive_proc_macro_test ``` The `bin_with_transitive_proc_macro` compile action will create the following intermediate file: `bazel-out/k8-fastbuild/bin/test/unit/rustdoc/bin_with_transitive_proc_macro.bin_with_transitive_proc_macro.573369dc-cgu.2.rcgu.o`, as will the `bin_with_transitive_proc_macro_test` action. These two files differ slightly (as the second action is for a test), namely the `bin_with_transitive_proc_macro` output has the following symbols: ``` 0000000000000000 T main 0000000000000000 t _ZN30bin_with_transitive_proc_macro4main17hfc292cc42314e131E U _ZN3std2rt10lang_start17h1dbc829c47cd61d9E ``` while the `bin_with_transitive_proc_macro_test` `.o` output looks like this: ``` 0000000000000000 T main 0000000000000000 t _ZN30bin_with_transitive_proc_macro4main17h28726504dc060f8dE U _ZN3std2rt10lang_start17h1dbc829c47cd61d9E U _ZN4test16test_main_static17h37e3d88407f5b40fE ``` Now, when the two actions run in parallel, it can happen that `bin_with_transitive_proc_macro` creates the output, and `bin_with_transitive_proc_macro_test` overwrites it. Then, at linking time for `bin_with_transitive_proc_macro`, `rustc` will complain: ``` note: ld.lld: error: undefined symbol: test::test_main_static::h37e3d88407f5b40f ``` This is because `bin_with_transitive_proc_macro` is not a test and as such is not linked against `libtest`. This PR fixes the issue by directing the compilation outputs of `rust_test` to be under a `test-{hash}` directory.
…lying lib (#2803) This PR also makes `rust_test` put its compilation outputs in the same directory as the `rust_library` rule (i.e. not in a `test-{hash}` subdirectory anymore). After this change both the `rust_library` and `rust_test` rules will put all its compilation outputs in the same directory, but there won't be any name collisions in non-sandboxed environments (see #1427 for more context). This is a partial rollback of 1018533 and 26344d4.
underlying lib This is a rollforward of bazelbuild#2803, but behind a feature flag. This PR also makes `rust_test` put its compilation outputs in the same directory as the `rust_library` rule (i.e. not in a `test-{hash}` subdirectory anymore). After this change both the `rust_library` and `rust_test` rules will put all its compilation outputs in the same directory, but there won't be any name collisions in non-sandboxed environments (see bazelbuild#1427 for more context). Issue: bazelbuild#2827
underlying lib This is a rollforward of bazelbuild#2803, but behind a feature flag. This PR also makes `rust_test` put its compilation outputs in the same directory as the `rust_library` rule (i.e. not in a `test-{hash}` subdirectory anymore). After this change both the `rust_library` and `rust_test` rules will put all its compilation outputs in the same directory, but there won't be any name collisions in non-sandboxed environments (see bazelbuild#1427 for more context). Issue: bazelbuild#2827
underlying lib This is a rollforward of bazelbuild#2803, but behind a feature flag. This PR also makes `rust_test` put its compilation outputs in the same directory as the `rust_library` rule (i.e. not in a `test-{hash}` subdirectory anymore). After this change both the `rust_library` and `rust_test` rules will put all its compilation outputs in the same directory, but there won't be any name collisions in non-sandboxed environments (see bazelbuild#1427 for more context). Issue: bazelbuild#2827
…lying lib (#2828) This is a rollforward of #2803, but behind the `incompatible_change_rust_test_compilation_output_directory` incompatible flag. This PR also makes `rust_test` put its compilation outputs in the same directory as the `rust_library` rule (i.e. not in a `test-{hash}` subdirectory anymore). After this change both the `rust_library` and `rust_test` rules will put all its compilation outputs in the same directory, but there won't be any name collisions in non-sandboxed environments (see #1427 for more context). Issue with context: #2827
https://blog.rust-lang.org/2022/06/30/Rust-1.62.0.html