Rollup of 4 pull requests #123565
Closed
Rollup of 4 pull requests #123565
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
The expected value is "<arch>-apple-watchos<major>.<minor>.0", i.e. "arm64_32-apple-watchos8.0.0". compiler/rustc_target/src/spec/base/apple/mod.rs contains functions that construct such string. There is an existing function `watchos_sim_llvm_target` which returns llvm target value for watchOS simulator. But there is none for watchOS device. This commit adds that missing function to align watchOS with other Apple platform targets.
Previously we left the panic hook we allocated
on main termination. Doing so makes Valgrind
report it as a reachable unfreed block.
In order to fix that use `panic::take_hook()` before
examining test results.
Example backtrace:
```
==146594== 16 bytes in 1 blocks are still reachable in loss record 1 of 1
==146594== at 0x4A390C5: malloc (vg_replace_malloc.c:442)
==146594== by 0x151336: alloc (alloc.rs:98)
==146594== by 0x151336: alloc_impl (alloc.rs:181)
==146594== by 0x151336: allocate (alloc.rs:241)
==146594== by 0x151336: exchange_malloc (alloc.rs:330)
==146594== by 0x151336: new<test::test_main::{closure_env#0}> (boxed.rs:217)
==146594== by 0x151336: test::test_main (lib.rs:124)
==146594== by 0x1522F9: test::test_main_static (lib.rs:160)
==146594== by 0x11E102: reachable_block_with_cargo_test::main (lib.rs:1)
==146594== by 0x11EABA: core::ops::function::FnOnce::call_once (function.rs:250)
==146594== by 0x11E76D: std::sys_common::backtrace::__rust_begin_short_backtrace (backtrace.rs:154)
==146594== by 0x11DFC0: std::rt::lang_start::{{closure}} (rt.rs:166)
==146594== by 0x177D3A: call_once<(), (dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> (function.rs:284)
==146594== by 0x177D3A: do_call<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> (panicking.rs:504)
==146594== by 0x177D3A: try<i32, &(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> (panicking.rs:468)
==146594== by 0x177D3A: catch_unwind<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> (panic.rs:142)
==146594== by 0x177D3A: {closure#2} (rt.rs:148)
==146594== by 0x177D3A: do_call<std::rt::lang_start_internal::{closure_env#2}, isize> (panicking.rs:504)
==146594== by 0x177D3A: try<isize, std::rt::lang_start_internal::{closure_env#2}> (panicking.rs:468)
==146594== by 0x177D3A: catch_unwind<std::rt::lang_start_internal::{closure_env#2}, isize> (panic.rs:142)
==146594== by 0x177D3A: std::rt::lang_start_internal (rt.rs:148)
==146594== by 0x11DF99: std::rt::lang_start (rt.rs:165)
```
Signed-off-by: Tal Gelbard <talgelbard1@gmail.com>
…, r=cuviper Drop panic hook after running tests Issue: rust-lang#119223 Previously we left the panic hook we allocated on main termination. Doing so makes Valgrind report it as a reachable unfreed block. In order to fix that use `panic::take_hook()` before examining test results. Example backtrace: ``` ==146594== 16 bytes in 1 blocks are still reachable in loss record 1 of 1 ==146594== at 0x4A390C5: malloc (vg_replace_malloc.c:442) ==146594== by 0x151336: alloc (alloc.rs:98) ==146594== by 0x151336: alloc_impl (alloc.rs:181) ==146594== by 0x151336: allocate (alloc.rs:241) ==146594== by 0x151336: exchange_malloc (alloc.rs:330) ==146594== by 0x151336: new<test::test_main::{closure_env#0}> (boxed.rs:217) ==146594== by 0x151336: test::test_main (lib.rs:124) ==146594== by 0x1522F9: test::test_main_static (lib.rs:160) ==146594== by 0x11E102: reachable_block_with_cargo_test::main (lib.rs:1) ==146594== by 0x11EABA: core::ops::function::FnOnce::call_once (function.rs:250) ==146594== by 0x11E76D: std::sys_common::backtrace::__rust_begin_short_backtrace (backtrace.rs:154) ==146594== by 0x11DFC0: std::rt::lang_start::{{closure}} (rt.rs:166) ==146594== by 0x177D3A: call_once<(), (dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> (function.rs:284) ==146594== by 0x177D3A: do_call<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> (panicking.rs:504) ==146594== by 0x177D3A: try<i32, &(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> (panicking.rs:468) ==146594== by 0x177D3A: catch_unwind<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> (panic.rs:142) ==146594== by 0x177D3A: {closure#2} (rt.rs:148) ==146594== by 0x177D3A: do_call<std::rt::lang_start_internal::{closure_env#2}, isize> (panicking.rs:504) ==146594== by 0x177D3A: try<isize, std::rt::lang_start_internal::{closure_env#2}> (panicking.rs:468) ==146594== by 0x177D3A: catch_unwind<std::rt::lang_start_internal::{closure_env#2}, isize> (panic.rs:142) ==146594== by 0x177D3A: std::rt::lang_start_internal (rt.rs:148) ==146594== by 0x11DF99: std::rt::lang_start (rt.rs:165) ```
Put checks that detect UB under their own flag below debug_assertions Implementation of rust-lang/compiler-team#725
…t, r=estebank Fix incorrect 'llvm_target' value used on watchOS target ## Issue `xcodebuild -create-xcframework` command doesn't recognize static libraries that are built on "arm64_32-apple-watchos" target. Here are steps to reproduce the issue on a Mac: 1. Install nightly toolchain `nightly-2024-03-27`. Needs this specific version, because newer nightly versions are broken on watchos target. 1. Create an empty library: `mkdir watchos-lib && cd watchos-lib && cargo init --lib`. 1. Add configuration `lib.crate-type=["staticlib"]` to Cargo.toml. 1. Build the library: `cargo +nightly-2024-03-27 build --release -Zbuild-std --target arm64_32-apple-watchos` 1. Run `xcodebuild -create-xcframework` to put the static library into a xcframework, which results in an error: ``` $ xcodebuild -create-xcframework -library target/arm64_32-apple-watchos/release/libwatchos_lib.a -output test.xcframework error: unable to determine the platform for the given binary '.../watchos-lib/target/arm64_32-apple-watchos/release/libwatchos_lib.a'; check your deployment version settings ``` ## Fix The root cause of this error is `xcodebuild` couldn't read `LC_BUILD_VERSION` from the static library to determine the library's target platform. And the reason it's missing is that an incorrect `llvm_target` value is used in `arm64_32-apple-watchos` target. The expected value is `<arch>-apple-watchos<major>.<minor>.0`, i.e. "arm64_32-apple-watchos8.0.0". The [.../apple/mod.rs](/~https://github.com/rust-lang/rust/blob/43f4f2a3b1a3d3fb3dbbbe4fde33fb97c780ee98/compiler/rustc_target/src/spec/base/apple/mod.rs#L321) file contains functions that construct such string. There is an existing function `watchos_sim_llvm_target` which returns llvm target value for watchOS simulator. But there is none for watchOS device. This PR adds that missing function to align watchOS with other Apple platform targets. To verify the fix, you can simply build a toolchain on this PR branch and repeat the steps above using the built local toolchain to verify the `xcodebuild -create-xcframework` command can create a xcframework successfully. Furthermore, you can verify `LC_BUILD_VERSION` contains correct info by using the simple shell script below to print `LC_BUILD_VERSION` of the static library that's built on watchos target: ```shell bin=target/arm64_32-apple-watchos/release/libwatchos_lib.a file=$(ar -t "$bin" | grep -E '\.o$' | head -n 1) ar -x "$bin" "$file" vtool -show-build-version "$file" ``` Here is an example output from my machine: ``` watchos_rust-495d6aaf3bccc08d.watchos_rust.35ba42bf9255ca9d-cgu.0.rcgu.o: Load command 1 cmd LC_BUILD_VERSION cmdsize 24 platform WATCHOS minos 8.0 sdk n/a ntools 0 ```
…errors Do not ICE on field access check on expr with `ty::Error` Fix rust-lang#123428
rustbot
added
S-waiting-on-review
|
@bors r+ p=4 rollup=never |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 6, 2024
…llaumeGomez Rollup of 4 pull requests Successful merges: - rust-lang#119224 (Drop panic hook after running tests) - rust-lang#123411 (Put checks that detect UB under their own flag below debug_assertions) - rust-lang#123446 (Fix incorrect 'llvm_target' value used on watchOS target) - rust-lang#123516 (Do not ICE on field access check on expr with `ty::Error`) r? `@ghost` `@rustbot` modify labels: rollup
|
💥 Test timed out |
bors
added
S-waiting-on-review
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.
Successful merges:
ty::Error#123516 (Do not ICE on field access check on expr withty::Error)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup