Redesign `intrinsic-test` to use simple comparison by sayantn · Pull Request #2063 · rust-lang/stdarch

sayantn · 2026-03-16T00:10:47Z

Currently intrinsic-test prints the outputs and then compares the outputs manually. This PR uses a different approach -- generate C wrappers for the intrinsics, link to them from Rust, and then just use simple rust tests to compare outputs

Blocked on #2095 #2096 #2099 #2100 #2101

sayantn · 2026-03-16T01:23:31Z

---- test_vdupq_n_f16 stdout ----

thread 'test_vdupq_n_f16' (2187) panicked at mod_0/src/lib.rs:13773:17:
assertion `left == right` failed: 
  left: [NiceF16(0.0), NiceF16(0.0), NiceF16(0.0), NiceF16(0.0), NiceF16(0.0), NiceF16(0.0), NiceF16(0.0), NiceF16(0.0)]
 right: [NiceF16(0.0), NiceF16(0.0), NiceF16(0.0), NiceF16(0.0), NiceF16(1.43e-5), NiceF16(0.0), NiceF16(-50430.0), NiceF16(1.79e-5)]

This seems weird (left is the Rust output, right is the C one, and NiceF16 is a wrapper which implements PartialEq as a == b || (a.is_nan() && b.is_nan())). This looks like ABI-related issue. For reference, the declaration looks like

unsafe extern "C" {
    fn vdup_n_f16_wrapper(value: f16) -> float16x4_t;
}

In fact most f16 tests fail in armv7. @folkertdev can you help?

Edit:

To work around this issue I have modified the tool to communicate with C via pointers (e.g. the C wrapper for _mm_add_ps looks like void _mm_add_ps_wrapper(__m128 *dst, const __m128* a, const __m128* b). This fixed the AArch64 and ARMv7 problems, but now the AArch64BE tests are failing, because apparently C and Rust have different pointer load semantics for matrix-like vectors (e.g. uint64x2x2_t) https://godbolt.org/z/j1d16z1P9

@Amanieu is this intended behavior or a bug?

sayantn · 2026-03-16T08:46:41Z

Btw the time gains are significant, it reduces the Arm and aarch64 times to 2-3 minutes, and the full x86 run (we did 20% previously) to around 12 mins for release and 17 mins for dev

folkertdev · 2026-03-16T19:40:36Z

Great work. Quick sanity check on f16, perhaps we're still using LLVM 21 to compile the C? If LLVM 21 is used (and also on windows apparently still with LLVM 22) then on some targets the ABI is inconsistent.

sayantn · 2026-03-16T20:06:47Z

@folkertdev ooh, that makes sense. I don't particularly care about windows, but we are using LLVM20 in the CI. I can change it to use the build from kernel.org

folkertdev · 2026-03-16T20:10:12Z

I'm seeing clang-18 here even https://triage.rust-lang.org/gha-logs/rust-lang/stdarch/67182959392?pr=2063. I'm not sure what the best solution is really. You could ask T-infra if they have ideas.

sayantn · 2026-03-16T20:14:58Z

yeah, but I can use the LLVM github builds or the kernel.org builds

tgross35 · 2026-03-16T20:56:46Z

Can f16 tests just be gated with #[cfg(target_has_reliable_f16)]? That's likely easier than working around the Windows and old LLVM failures.

sayantn · 2026-03-16T20:58:30Z

@tgross35 the f16 tests are mostly fine now. More concerning is that a lot of tests are failing in all 3 arm archs, e.g. vzipq. The C version seems to return all zeros

edit: sorry, my mistake, they are still failing in ARMv7. I will gate them against the flag

folkertdev · 2026-03-16T21:20:26Z

With LLVM 22 f16 should work on armv7 though?

tgross35 · 2026-03-16T21:27:37Z

FTZ/DAZ-related perhaps?

sayantn · 2026-03-17T06:01:39Z

FTZ/DAZ-related perhaps?

I don't really think so, the outputs seem completely distinct.

I noticed that vzipq etc was failing so I tried out the assemblies.
In aarch64_be-unknown-linux-gnu,

use core::arch::aarch64::*;

#[unsafe(no_mangle)]
#[target_feature(enable = "neon")]
pub unsafe extern "C" fn foo(dst: *mut uint8x16x2_t, a: *const uint8x16_t, b: *const uint8x16_t) {
    unsafe {
        *dst = vzipq_u8(*a, *b);
    }
}

produces

foo:
        ld1 { v0.16b }, [x1]
        ld1 { v1.16b }, [x2]
        add x8, x0, #16
        zip1 v2.16b, v0.16b, v1.16b
        zip2 v0.16b, v0.16b, v1.16b
        st1 { v2.16b }, [x0]
        st1 { v0.16b }, [x8]
        ret

But the C code seemingly has different behavior on GCC and clang https://godbolt.org/z/T3YnrejjG

@adamgemmell can you help in this?

adamgemmell · 2026-03-18T14:55:11Z

I'm not sure it will fix your issue but the difference in instructions comes from the fact that in arm_neon.h, they reverse every vector before and after the operation on big endian. It's not always actually necessary so we only do it if it's broken without it - however, the intrinsic test tool doesn't detect the difference in behaviour because both arguments it picks are identical.

e.g.:

| a               | 15 | 14 | 13 | ... | 2  | 1  | 0  |
| b               | 31 | 30 | 29 | ... | 18 | 17 | 16 |
| a = rev(a)      | 0  | 1  | 2  | ... | 13 | 14 | 15 |
| b = rev(b)      | 16 | 17 | 18 | ... | 29 | 30 | 31 |
| ret = zip(a, b) | 0  | 16 | 1  | ... | 30 | 15 | 31 |
| rev(ret)        | 31 | 15 | 30 | ... | 1  | 16 | 0  |

adamgemmell · 2026-03-18T15:53:48Z

You can try adding big_endian_inverse: true to the definition in the yaml, regenerating to see if it changes anything. We can probably offset the pointers to the values array for arguments slightly to ensure they're different

Also I don't actually see vzipq_u8 on the latest CI run, why is that?

sayantn · 2026-03-18T16:25:37Z

Also I don't actually see vzipq_u8 on the latest CI run, why is that?

I have no idea, I can confirm that locally the test is generated and run.

You can try adding big_endian_inverse: true to the definition in the yaml, regenerating to see if it changes anything. We can probably offset the pointers to the values array for arguments slightly to ensure they're different

I will check. Thanks

Edit: @adamgemmell adding big_endian_inverse: true to the functions seem to work. The only question remains is that is it the correct behavior, or is clang buggy here

Edit2: sorry, vzipq_u8 is not getting tested even locally. I will look into it

adamgemmell · 2026-03-18T17:36:27Z

None of the unsigned variants of vzipq seem to be seen there, weird.

I'd quite like to know why this patch detects the difference - when I looked locally the codegen of the tests seemed very similar

sayantn · 2026-03-18T18:19:32Z

Yeah I fixed the test not being included, I used / instead of div_ceil when computing the chunk sizes, so the last module wasn't getting included 😅

folkertdev

I'm very excited for it too!

Overall I do think it would help to extract what is feasible into separate PRs. E.g. some of the dockerfile and yml changes at least seem like they could be merged separately.

View changes since this review

folkertdev · 2026-05-01T12:29:08Z

-      - [int8x16_t, ' static_assert_uimm_bits!(N, 4);', 'unsafe { match N & 0b1111 { 0 => simd_shuffle!(a, b, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]), 1 => simd_shuffle!(a, b, [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]), 2 => simd_shuffle!(a, b, [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17]), 3 => simd_shuffle!(a, b, [3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18]), 4 => simd_shuffle!(a, b, [4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]), 5 => simd_shuffle!(a, b, [5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]), 6 => simd_shuffle!(a, b, [6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21]), 7 => simd_shuffle!(a, b, [7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22]), 8 => simd_shuffle!(a, b, [8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23]), 9 => simd_shuffle!(a, b, [9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24]), 10 => simd_shuffle!(a, b, [10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25]), 11 => simd_shuffle!(a, b, [11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26]), 12 => simd_shuffle!(a, b, [12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27]), 13 => simd_shuffle!(a, b, [13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28]), 14 => simd_shuffle!(a, b, [14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29]), 15 => simd_shuffle!(a, b, [15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30]), _ => unreachable_unchecked(), } }']
-      - [uint8x16_t, ' static_assert_uimm_bits!(N, 4);', 'unsafe { match N & 0b1111 { 0 => simd_shuffle!(a, b, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]), 1 => simd_shuffle!(a, b, [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]), 2 => simd_shuffle!(a, b, [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17]), 3 => simd_shuffle!(a, b, [3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18]), 4 => simd_shuffle!(a, b, [4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]), 5 => simd_shuffle!(a, b, [5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]), 6 => simd_shuffle!(a, b, [6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21]), 7 => simd_shuffle!(a, b, [7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22]), 8 => simd_shuffle!(a, b, [8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23]), 9 => simd_shuffle!(a, b, [9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24]), 10 => simd_shuffle!(a, b, [10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25]), 11 => simd_shuffle!(a, b, [11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26]), 12 => simd_shuffle!(a, b, [12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27]), 13 => simd_shuffle!(a, b, [13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28]), 14 => simd_shuffle!(a, b, [14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29]), 15 => simd_shuffle!(a, b, [15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30]), _ => unreachable_unchecked(), } }']
-      - [poly8x16_t, ' static_assert_uimm_bits!(N, 4);', 'unsafe { match N & 0b1111 { 0 => simd_shuffle!(a, b, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]), 1 => simd_shuffle!(a, b, [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]), 2 => simd_shuffle!(a, b, [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17]), 3 => simd_shuffle!(a, b, [3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18]), 4 => simd_shuffle!(a, b, [4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]), 5 => simd_shuffle!(a, b, [5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]), 6 => simd_shuffle!(a, b, [6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21]), 7 => simd_shuffle!(a, b, [7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22]), 8 => simd_shuffle!(a, b, [8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23]), 9 => simd_shuffle!(a, b, [9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24]), 10 => simd_shuffle!(a, b, [10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25]), 11 => simd_shuffle!(a, b, [11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26]), 12 => simd_shuffle!(a, b, [12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27]), 13 => simd_shuffle!(a, b, [13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28]), 14 => simd_shuffle!(a, b, [14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29]), 15 => simd_shuffle!(a, b, [15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30]), _ => unreachable_unchecked(), } }']
+      - [int8x16_t, 'match N & 0b1111 { 0 => simd_shuffle!(a, b, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]), 1 => simd_shuffle!(a, b, [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]), 2 => simd_shuffle!(a, b, [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17]), 3 => simd_shuffle!(a, b, [3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18]), 4 => simd_shuffle!(a, b, [4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]), 5 => simd_shuffle!(a, b, [5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]), 6 => simd_shuffle!(a, b, [6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21]), 7 => simd_shuffle!(a, b, [7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22]), 8 => simd_shuffle!(a, b, [8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23]), 9 => simd_shuffle!(a, b, [9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24]), 10 => simd_shuffle!(a, b, [10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25]), 11 => simd_shuffle!(a, b, [11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26]), 12 => simd_shuffle!(a, b, [12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27]), 13 => simd_shuffle!(a, b, [13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28]), 14 => simd_shuffle!(a, b, [14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29]), 15 => simd_shuffle!(a, b, [15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30]), _ => unreachable_unchecked(), }']


any chance we can lift this pattern out into a normal function that gets imported and used?

Instead of doing an `as {i,u}16` cast, we can use the same LLVM intrinsics as when converting to `{i,u}{32,64}`, which is what Clang does and ensures the intrinsic result matches.

Earlier patches added `big_endian_inverse` and used `transmute` instead of using `vreinterpret` due to an LLVM bug that has since been resolved

Instead of duplicating the stability attribute, re-use the `neon-stable` anchor through

This enables the `big_endian_inverse` transformation to apply to this intrinsic.

This enables the `big_endian_inverse` transformation to apply to these intrinsics.

This enables the `big_endian_inverse` transform to apply to these intrinsics.

This enables the `big_endian_inverse` transform to apply to this intrinsic.

This enables the `big_endian_inverse` transformation to apply to some of these intrinsics only when appropriate.

Only this definition needs `big_endian_inverse` to pass tests under big endian, but `_laneq_f64`, `s_lane_f32`, and `s_laneq_f32`.

Changes the definition of `vabdl_high_u{8,16,32}` to match that of `vabdl_high_s{8,16,32}` so that the `big_endian_inverse` transformation can apply.

Writing these intrinsics in terms of the `vqtbl_$ty` functions rather than the `vqtbl` helper function preserves the behaviour while making them work in big endian.

Writing these intrinsics in terms of the `vqtbx_$ty` functions rather than the `vqtbx` helper function preserves the behaviour while making them work in big endian.

Some intrinsics needed the big endian inverse transform but it wasn't being applied automatically.

Manually written tests for `vcopy_laneq`, `vget{,q}_{high,low,lane}`, `vcombine` and `vaddw_high` don't account for the expected differences in output for big endian intrinsics and given that they duplicate the testing of `intrinsic-test`, can be removed.

Some intrinsics optimise to different instructions on big endian which leads to `assert_instr` failing

sayantn · 2026-05-01T23:40:32Z

@folkertdev @davidtwco I will be splitting the commits into a few PRs, e.g. some CI changes and some changes to stdarch-gen-arm that can be landed independently. I have already put up 5 PRs, I will see if I can split more

sayantn force-pushed the intrinsic-test branch 4 times, most recently from feb1dcd to 6ef8b8f Compare March 16, 2026 00:59

sayantn force-pushed the intrinsic-test branch 4 times, most recently from e2346ff to db1b2ca Compare March 16, 2026 06:16

sayantn force-pushed the intrinsic-test branch 2 times, most recently from ce53e81 to 76dd339 Compare March 16, 2026 20:48

sayantn force-pushed the intrinsic-test branch from 76dd339 to c4b138f Compare March 17, 2026 06:18

This comment has been minimized.

Sign in to view

sayantn force-pushed the intrinsic-test branch 2 times, most recently from a057d30 to 2dfa840 Compare April 24, 2026 20:40

folkertdev reviewed May 1, 2026

View reviewed changes

sayantn and others added 27 commits May 1, 2026 19:41

Generate rust bindings and test code

0ffa0de

Remove the Language enum

56de6fe

Modify the CI scripts to work with the new design

fb583f4

Use pointers for the C definitions to resolve ABI inconsistencies

de1560b

gen-arm: use LLVM intrinsics for f16 to {i,u}16

1542202

Instead of doing an `as {i,u}16` cast, we can use the same LLVM intrinsics as when converting to `{i,u}{32,64}`, which is what Clang does and ensures the intrinsic result matches.

gen-arm: resolve outdated big_endian_inverse todo

4dc3a0f

Earlier patches added `big_endian_inverse` and used `transmute` instead of using `vreinterpret` due to an LLVM bug that has since been resolved

gen-arm: use neon-stable anchor throughout

3eefef9

Instead of duplicating the stability attribute, re-use the `neon-stable` anchor through

gen-arm: port vcopy_lane_{s,u,p,f}64 to generator

c4211fa

This enables the `big_endian_inverse` transformation to apply to this intrinsic.

gen-arm: port vcopy_laneq_{f,u,s,p}64 to generator

e676354

This enables the `big_endian_inverse` transformation to apply to these intrinsics.

gen-arm: port vget_{high,low}{p,f}64 to generator

a822340

This enables the `big_endian_inverse` transform to apply to these intrinsics.

gen-arm: port vgetq_lane_f64 to generator

11ea820

This enables the `big_endian_inverse` transform to apply to this intrinsic.

gen-arm: port vcombine_f64 to generator

eb925af

This enables the `big_endian_inverse` transform to apply to this intrinsic.

gen-arm: split vreinterpret defn into multiple

645d944

This enables the `big_endian_inverse` transformation to apply to some of these intrinsics only when appropriate.

gen-arm: split vfmsd_lane_f64 from other defns

1d771ee

Only this definition needs `big_endian_inverse` to pass tests under big endian, but `_laneq_f64`, `s_lane_f32`, and `s_laneq_f32`.

gen-arm: change defn of vabdl_high_u{8,16,32}

75b7f0e

Changes the definition of `vabdl_high_u{8,16,32}` to match that of `vabdl_high_s{8,16,32}` so that the `big_endian_inverse` transformation can apply.

gen-arm: write vtbl{1,2,3,4} in terms of vqtbl

9f609cf

Writing these intrinsics in terms of the `vqtbl_$ty` functions rather than the `vqtbl` helper function preserves the behaviour while making them work in big endian.

gen-arm: write vtbx{1,2,3,4} in terms of vqtbx

432ad98

Writing these intrinsics in terms of the `vqtbx_$ty` functions rather than the `vqtbx` helper function preserves the behaviour while making them work in big endian.

gen-arm: toggle big_endian_inverse where reqd.

3f104a4

Some intrinsics needed the big endian inverse transform but it wasn't being applied automatically.

gen-arm: fix vmlal, vmlsl and vmull

e2f577c

gen-arm: fix vfmlal and vfmlsl

33aeb3d

gen-arm: fix vcmla

cb7006d

gen-arm: skip assert_instr on big-endian

dff0eac

Some intrinsics optimise to different instructions on big endian which leads to `assert_instr` failing

Fix _mm_sm3rnds2_epi32

0139c67

Disable some tests in x86 due to CI failures

a84a9e5

Use latest clang versions from kernel.org

a1bed91

revert changing number of passes depending on number of parameters

d542886

sayantn force-pushed the intrinsic-test branch from 185efd7 to d542886 Compare May 1, 2026 14:13

Conversation

sayantn commented Mar 16, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sayantn commented Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sayantn commented Mar 16, 2026

Uh oh!

folkertdev commented Mar 16, 2026

Uh oh!

sayantn commented Mar 16, 2026

Uh oh!

folkertdev commented Mar 16, 2026

Uh oh!

sayantn commented Mar 16, 2026

Uh oh!

tgross35 commented Mar 16, 2026

Uh oh!

sayantn commented Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

folkertdev commented Mar 16, 2026

Uh oh!

tgross35 commented Mar 16, 2026

Uh oh!

sayantn commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adamgemmell commented Mar 18, 2026

Uh oh!

adamgemmell commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sayantn commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adamgemmell commented Mar 18, 2026

Uh oh!

sayantn commented Mar 18, 2026

Uh oh!

This comment has been minimized.

folkertdev left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

folkertdev May 1, 2026

Choose a reason for hiding this comment

Uh oh!

sayantn commented May 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

sayantn commented Mar 16, 2026 •

edited by rustbot

Loading

sayantn commented Mar 16, 2026 •

edited

Loading

sayantn commented Mar 16, 2026 •

edited

Loading

sayantn commented Mar 17, 2026 •

edited

Loading

adamgemmell commented Mar 18, 2026 •

edited

Loading

sayantn commented Mar 18, 2026 •

edited

Loading

folkertdev left a comment •

edited by rustbot

Loading

sayantn commented May 1, 2026 •

edited

Loading