Conversation
b68bc57 to
e9dc1bb
Compare
|
r? @JohnTitor rustbot has assigned @JohnTitor. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
cc MSVC target maintainers: @ChrisDenton @dpaoliello @Fulgen301 @lambdageek @sivadeilra @wesleywiser |
|
(Given this touches debuginfo tests this should probably get a |
|
@bors try jobs=x86_64-msvc-,i686-msvc-,aarch64-msvc-,aarch64-apple- |
1 similar comment
|
@bors try jobs=x86_64-msvc-,i686-msvc-,aarch64-msvc-,aarch64-apple- |
This comment has been minimized.
This comment has been minimized.
Add Natvis visualiser and debuginfo tests for `f128` try-job: x86_64-msvc-* try-job: i686-msvc-* try-job: aarch64-msvc-* try-job: aarch64-apple-*
This comment has been minimized.
This comment has been minimized.
|
💔 Test for 816a2f0 failed: CI. Failed jobs:
|
e9dc1bb to
19f719c
Compare
|
According to the table on Wikipedia, there isn't any Xcode versions yet with LLDB 22 or later, so I've ignored the |
|
@bors try jobs=x86_64-msvc-,i686-msvc-,aarch64-msvc-,aarch64-apple- |
This comment has been minimized.
This comment has been minimized.
Add Natvis visualiser and debuginfo tests for `f128` try-job: x86_64-msvc-* try-job: i686-msvc-* try-job: aarch64-msvc-* try-job: aarch64-apple-*
|
@rustbot review |
This comment has been minimized.
This comment has been minimized.
Add Natvis visualiser and debuginfo tests for `f128`
To render f128s in debuggers on MSVC targets, this PR changes the compiler to output `f128`s as `struct f128 { low_bits: u64, high_bits: u64 }`, and includes a Natvis visualiser that displays the float in hexdecimal format (similar to the `LowerHex` impl in rust-lang#160626), as unlike `f16` there's no larger supported float format to convert to and trying to write a float to decimal string converter in Natvis didn't seem practical. gdb, lldb and cdb tests are also included for `f128`, although gdb does not yet correctly identify the float format.
I did consider also displaying a `double` approximation of the `f128` (as the debugger will convert that to a decimal string) but decided against it as `f64` has a significantly smaller exponent range too (meaning very large or small `f128`s couldn't have an approximation anyway) and `cdb` and `WinDbg` both seem to round all floating-point numbers to 6 decimal places, meaning the displayed number is (double) rounded even further than `f64` precision and is useless for tiny values.
Closes rust-lang#121837
Tracking issue: rust-lang#116909
…uwer Rollup of 15 pull requests Successful merges: - #160401 (sparc: make ABI consistent with clang) - #161777 (Add Natvis visualiser and debuginfo tests for `f128`) - #162423 (Rename the src install build step to rust-src.) - #162740 (stdarch subtree update) - #162824 (link Enzyme and the offload with in-tree lld if possible) - #162832 (add `Div` and `Mul` for `Complex<{float}>`) - #161005 (fix: unfulfilled nested dead code lint) - #161803 (Fix docs of make_ascii_lowercase/make_ascii_upercase) - #162256 (Add mentions to sync back `RELEASES.md` to the `main` branch) - #162661 (simplify `Target::GenericParam`) - #162666 (Tidy footnote in `platform-support.md`) - #162803 (docs(num): add documentation for `NonZero::from_str`) - #162906 (Move more `rustdoc-html` tests in the right location) - #162922 (An assortment of polonius tweaks) - #162930 (Use niche length type for strlen to guarantee `isize::MAX` bound)
Add Natvis visualiser and debuginfo tests for `f128`
To render f128s in debuggers on MSVC targets, this PR changes the compiler to output `f128`s as `struct f128 { low_bits: u64, high_bits: u64 }`, and includes a Natvis visualiser that displays the float in hexdecimal format (similar to the `LowerHex` impl in rust-lang#160626), as unlike `f16` there's no larger supported float format to convert to and trying to write a float to decimal string converter in Natvis didn't seem practical. gdb, lldb and cdb tests are also included for `f128`, although gdb does not yet correctly identify the float format.
I did consider also displaying a `double` approximation of the `f128` (as the debugger will convert that to a decimal string) but decided against it as `f64` has a significantly smaller exponent range too (meaning very large or small `f128`s couldn't have an approximation anyway) and `cdb` and `WinDbg` both seem to round all floating-point numbers to 6 decimal places, meaning the displayed number is (double) rounded even further than `f64` precision and is useless for tiny values.
Closes rust-lang#121837
Tracking issue: rust-lang#116909
…uwer Rollup of 15 pull requests Successful merges: - #160401 (sparc: make ABI consistent with clang) - #161777 (Add Natvis visualiser and debuginfo tests for `f128`) - #162423 (Rename the src install build step to rust-src.) - #162740 (stdarch subtree update) - #162824 (link Enzyme and the offload with in-tree lld if possible) - #161005 (fix: unfulfilled nested dead code lint) - #161803 (Fix docs of make_ascii_lowercase/make_ascii_upercase) - #162256 (Add mentions to sync back `RELEASES.md` to the `main` branch) - #162661 (simplify `Target::GenericParam`) - #162666 (Tidy footnote in `platform-support.md`) - #162803 (docs(num): add documentation for `NonZero::from_str`) - #162906 (Move more `rustdoc-html` tests in the right location) - #162922 (An assortment of polonius tweaks) - #162929 (Update unicode_data to Unicode version 18.0.0) - #162930 (Use niche length type for strlen to guarantee `isize::MAX` bound)
Add Natvis visualiser and debuginfo tests for `f128`
To render f128s in debuggers on MSVC targets, this PR changes the compiler to output `f128`s as `struct f128 { low_bits: u64, high_bits: u64 }`, and includes a Natvis visualiser that displays the float in hexdecimal format (similar to the `LowerHex` impl in rust-lang#160626), as unlike `f16` there's no larger supported float format to convert to and trying to write a float to decimal string converter in Natvis didn't seem practical. gdb, lldb and cdb tests are also included for `f128`, although gdb does not yet correctly identify the float format.
I did consider also displaying a `double` approximation of the `f128` (as the debugger will convert that to a decimal string) but decided against it as `f64` has a significantly smaller exponent range too (meaning very large or small `f128`s couldn't have an approximation anyway) and `cdb` and `WinDbg` both seem to round all floating-point numbers to 6 decimal places, meaning the displayed number is (double) rounded even further than `f64` precision and is useless for tiny values.
Closes rust-lang#121837
Tracking issue: rust-lang#116909
…uwer Rollup of 14 pull requests Successful merges: - #160401 (sparc: make ABI consistent with clang) - #161777 (Add Natvis visualiser and debuginfo tests for `f128`) - #162740 (stdarch subtree update) - #162824 (link Enzyme and the offload with in-tree lld if possible) - #161005 (fix: unfulfilled nested dead code lint) - #161803 (Fix docs of make_ascii_lowercase/make_ascii_upercase) - #162256 (Add mentions to sync back `RELEASES.md` to the `main` branch) - #162661 (simplify `Target::GenericParam`) - #162666 (Tidy footnote in `platform-support.md`) - #162803 (docs(num): add documentation for `NonZero::from_str`) - #162906 (Move more `rustdoc-html` tests in the right location) - #162922 (An assortment of polonius tweaks) - #162929 (Update unicode_data to Unicode version 18.0.0) - #162930 (Use niche length type for strlen to guarantee `isize::MAX` bound)
|
💔 I suspect this PR failed tests as part of a rollup After fixing the problem, consider running a try job for the failed job before re-approving. Link to failure: #162973 (comment) |
|
This pull request was unapproved. This PR was contained in a rollup (#162973), which was unapproved. |
167c7bd to
b7bad07
Compare
|
This PR was contained in a rollup (#162973), which was closed. |
|
Test fails locally on @bors try jobs=test-i686-gnu-nopt-1 |
This comment has been minimized.
This comment has been minimized.
Add Natvis visualiser and debuginfo tests for `f128` try-job: test-i686-gnu-nopt-1
|
@rustbot review |
|
@bors r+ |
Add Natvis visualiser and debuginfo tests for `f128`
To render f128s in debuggers on MSVC targets, this PR changes the compiler to output `f128`s as `struct f128 { low_bits: u64, high_bits: u64 }`, and includes a Natvis visualiser that displays the float in hexdecimal format (similar to the `LowerHex` impl in rust-lang#160626), as unlike `f16` there's no larger supported float format to convert to and trying to write a float to decimal string converter in Natvis didn't seem practical. gdb, lldb and cdb tests are also included for `f128`, although gdb does not yet correctly identify the float format.
I did consider also displaying a `double` approximation of the `f128` (as the debugger will convert that to a decimal string) but decided against it as `f64` has a significantly smaller exponent range too (meaning very large or small `f128`s couldn't have an approximation anyway) and `cdb` and `WinDbg` both seem to round all floating-point numbers to 6 decimal places, meaning the displayed number is (double) rounded even further than `f64` precision and is useless for tiny values.
Closes rust-lang#121837
Tracking issue: rust-lang#116909
View all comments
To render f128s in debuggers on MSVC targets, this PR changes the compiler to output
f128s asstruct f128 { low_bits: u64, high_bits: u64 }, and includes a Natvis visualiser that displays the float in hexdecimal format (similar to theLowerHeximpl in #160626), as unlikef16there's no larger supported float format to convert to and trying to write a float to decimal string converter in Natvis didn't seem practical. gdb, lldb and cdb tests are also included forf128, although gdb does not yet correctly identify the float format.I did consider also displaying a
doubleapproximation of thef128(as the debugger will convert that to a decimal string) but decided against it asf64has a significantly smaller exponent range too (meaning very large or smallf128s couldn't have an approximation anyway) andcdbandWinDbgboth seem to round all floating-point numbers to 6 decimal places, meaning the displayed number is (double) rounded even further thanf64precision and is useless for tiny values.Closes #121837
Tracking issue: #116909