`rustc_scalable_vector(N)` #143924

davidtwco · 2025-07-14T11:13:12Z

Supercedes #118917.

Initial experimental implementation of rust-lang/rfcs#3838. Introduces a rustc_scalable_vector(N) attribute that can be applied to types with a single [$ty] field (for u{16,32,64}, i{16,32,64}, f{32,64}, bool). rustc_scalable_vector types are lowered to scalable vectors in the codegen backend.

As with any unstable feature, there will necessarily be follow-ups as we experiment and find cases that we've not considered or still need some logic to handle, but this aims to be a decent baseline to start from.

See #145052 for request for a lang experiment.

rustbot · 2025-07-14T11:13:17Z

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-07-14T11:13:21Z

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

Some changes occurred in compiler/rustc_attr_data_structures

cc @jdonszelmann

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the platform-builtins intrinsics. Make sure the
LLVM backend as well as portable-simd gets adapted for the changes.

cc @antoyo, @GuillaumeGomez, @bjorn3, @calebzulawski, @programmerjake

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

changes to the core type system

cc @compiler-errors, @lcnr

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

davidtwco · 2025-07-14T11:21:46Z

I've changed this back to a draft and marked it as S-waiting-on-author while I rebase it and get the approval for an experimental implementation to go ahead.

workingjubilee

I do not intend to have repr(simd) survive this year, so I do not think this should be added.

davidtwco · 2025-07-14T16:09:12Z

I do not intend to have repr(simd) survive this year, so I do not think this should be added.

Could you elaborate?

workingjubilee · 2025-07-14T16:10:18Z

I intend to replace it with an approach based on lang items for a variety of reasons, one of them being that to start with, the repr(simd) "attribute" does not compose and should not.

r? @workingjubilee

workingjubilee

Some initial questions from my first pass of reading.

View changes since this review

workingjubilee · 2025-12-08T10:09:22Z

compiler/rustc_abi/src/layout.rs

+    Fixed,
+}
+
+fn vector_type_layout<FieldIdx, VariantIdx, F>(


absorbs the former contents of simd_type

Yeah, simd_type and now scalable_vector_type just forward to this

compiler/rustc_abi/src/lib.rs

compiler/rustc_codegen_gcc/src/type_of.rs

workingjubilee · 2025-12-08T10:15:03Z

library/core/src/intrinsics/simd.rs

+/// Replacement for `transmute`, specifically for use with scalable SIMD types.
+#[rustc_intrinsic]
+#[rustc_nounwind]
+pub unsafe fn simd_reinterpret<Src, Dst>(src: Src) -> Dst;


Hmm. For what purpose? Is there some way in which this is not transmute_unchecked? Is it just to attempt to bypass MIR implementation?

This was a leftover from when these types weren't Sized, I've changed it to transmute_unchecked in the test that uses it, and we'll need to update the stdarch intrinsic generator to use it too once we start generating the intrinsics.

workingjubilee · 2025-12-08T10:19:11Z

compiler/rustc_public/src/abi.rs

+            // FIXME(repr_scalable): Scalable vectors are `Sized` while the `sized_hierarchy`
+            // feature is not yet fully implemented


Hmm, what is specifically missing for us to be able to make this uh... less-Sized? It's "these are Sized but not const Sized right?" So this should still return false after that? Arguably the problem here isn't that the answer of false is wrong, it's that the signature furnishes a dubious answer for the question once we're deeper into the sized_hierarchy impl solidifying, because it won't be one well-answered by a simple bool anymore.

Exactly that, these types will remain Sized, just not const Sized, and so technically this will still return true but what is_unsized is actually asking becomes a big more ambiguous and we'll probably change this function when we introduce const sizedness to clear that up

workingjubilee · 2025-12-08T10:21:57Z

compiler/rustc_monomorphize/src/mono_checks/abi_check.rs

+/// Are vector registers used?
+enum UsesVectorRegisters {
+    /// e.g. `neon`
+    FixedVector,
+    /// e.g. `sve`
+    ScalableVector,
+    No,
+}
+
+/// Determines whether the combination of `mode` and `repr` will use fixed vector registers,
+/// scalable vector registers or no vector registers.
+fn uses_vector_registers(mode: &PassMode, repr: &BackendRepr) -> UsesVectorRegisters {
    match mode {
-        PassMode::Ignore | PassMode::Indirect { .. } => false,
-        PassMode::Cast { pad_i32: _, cast } => {
-            cast.prefix.iter().any(|r| r.is_some_and(|x| x.kind == RegKind::Vector))
-                || cast.rest.unit.kind == RegKind::Vector
+        PassMode::Ignore | PassMode::Indirect { .. } => UsesVectorRegisters::No,
+        PassMode::Cast { pad_i32: _, cast }
+            if cast.prefix.iter().any(|r| r.is_some_and(|x| x.kind == RegKind::Vector))
+                || cast.rest.unit.kind == RegKind::Vector =>
+        {
+            UsesVectorRegisters::FixedVector
+        }
+        PassMode::Direct(..) | PassMode::Pair(..)
+            if matches!(repr, BackendRepr::SimdVector { .. }) =>
+        {
+            UsesVectorRegisters::FixedVector
        }
-        PassMode::Direct(..) | PassMode::Pair(..) => matches!(repr, BackendRepr::SimdVector { .. }),
+        PassMode::Direct(..) | PassMode::Pair(..)
+            if matches!(repr, BackendRepr::ScalableVector { .. }) =>
+        {
+            UsesVectorRegisters::ScalableVector
+        }
+        _ => UsesVectorRegisters::No,
    }


Huh, I didn't realize this function existed. It is... answering a different question than it claims to. Not something we have to fix today, just making a note to myself.

Specifically, a function that uses a floating-point type may also use a vector register in the actual hardware, so it's more like "should this use the vector-by-value ABI?" which is... a mouthful, so I'm not sure that's a better actual function name.

I've not made any changes here but happy to rename the function if we wanted

I guess you are diffing its callsites anyways to account for "it's not a bool anymore"? Yeah, if passes_vectors_by_value sounds good then that might be nice, but I'm not particularly fussed here, I can always submit a PR myself after this one lands.

compiler/rustc_mir_transform/src/coroutine.rs

Amanieu · 2025-12-08T12:22:19Z

I don't think that making scalable vectors a non-const Sized type will work with SME since the size of scalable vectors can change depending on attributes placed on a function (ACLE spec). This is because there are 2 vector lengths (normal & streaming) and the length can changed based on CPU state. In C, the CPU state is controlled via function attributes, specifically:

In a normal function, vectors use the normal VL.
In a locally streaming function, vectors use the streaming VL.
In a streaming-compatible function, vectors use the VL of their caller.

Additionally, we will need to add compile-time checks to ensure scalable vectors aren't passed as arguments or returned across a mode change (ACLE spec). This essentially means that we can't support the use of scalable vectors in generic function signatures.

I think the better approach is to go back to the original design in #118917 where scalable vectors are essentially extern types to which we add some capabilities. This avoids issues with generics since these types can never be passed as arguments or returned in a generic context.

This design can still make use of the Sized type hierarchy since we still need the distinction between MetaSized and Unsized, with scalable vectors being the latter.

programmerjake · 2025-12-08T16:16:32Z

In C, the CPU state is controlled via function attributes, specifically:

In a normal function, vectors use the normal VL.

In a locally streaming function, vectors use the streaming VL.

In a streaming-compatible function, vectors use the VL of their caller.

tbh that sounds more like what we want is for Arm's scalable vectors to have a const-generic argument that's implicitly set by the surrounding function's mode which is either known (normal and locally-streaming functions), or a const-generic that's implicitly set by the caller (streaming-compatible functions). passing/returning scalable vectors between incompatible modes would then just produce a type error due to the const-generic argument not matching, but you can pass scalable vectors between compatible modes since the compiler can see the const-generic matches.

workingjubilee · 2025-12-08T19:53:47Z

@Amanieu My question is essentially as @programmerjake said: is there a reason that the SME and SVE modes are not two-or-more types, then? Whether the mode is a generic parameter or not is not too important to me, but it does seem intuitive to treat it as such. It's not like we can do FFI without knowing the mode, right?

workingjubilee · 2025-12-08T20:06:52Z

Documentation we'll want to reference while discussing this:

https://llvm.org/docs/AArch64SME.html

workingjubilee · 2025-12-08T23:01:55Z

@programmerjake I am sure Amanieu will provide more information, but one thing he pointed out when I asked in another context is that we would have to inhibit usage of SVE and SME types in the same function, because LLVM doesn't support switching modes except on function boundaries.

However, it seems we will have to implement compile-time handling regarding functions for SVE and SME either way, so I suspect using the tools we already have for such would be better. We already have 3 types of functions which each require compile-time checking, after all.

Amanieu · 2025-12-09T01:49:39Z

I don't think having 2 separate types for SVE and SME vectors is going to work. The main issue is that it's absolutely not possible to have scalable locals of 2 different modes in the same function. LLVM doesn't support it, and for good reason since even calculating the stack offsets for locals would involve several SME/SVE mode switches. The problem is that since these types would be runtime-sized, you would be able to smuggle those types into a function in various ways other than parameters and return values, and there's no way you can enforce this in a generic context.

Amanieu · 2025-12-09T01:51:16Z

The main advantage of making SVE vectors fully unsized is that it allows us to reliably determine, before monomorphization, whether the signature of a function has SVE locals, parameters or return values. This means that:

We can always pass these in registers since we can guarantee that both the caller and callee have the sve target feature enabled.
We don't need to worry about code doing size_of_val(&*sve_ptr) in a generic function that doesn't have the sve target feature because fully unsized types (like extern types) can't be dereferenced.
Constraints on passing values over the streaming/non-streaming boundary can be enforced pre-monomorphization. This also means that we never have to worry about having both SME and SVE locals in the same function. Arguably it's also possible to achieve this by rejecting any non-const-sized arguments at such boundaries.

The downsides are:

We can't take the address of an SVE local. This usually isn't needed in practice since intrinsics are normally used to read data into and out of SVE vectors.
We can't use SVE vectors in generic code that passes or returns such values, since that requires Sized. This also isn't a huge issue in practice since SVE code will tend to stick to SVE intrinsics instead of using generic code.

Overall I think the advantages outweigh the inconvenients and result in a simpler implementation in the compiler. It is also forward-compatible with making these types runtime-sized in the future.

workingjubilee · 2025-12-09T03:24:53Z

Hmmmm. Only requiring signature checking does help...

I think I'm not overly attached to a specific direction but I'd like to have the FIXMEs reflect our current inclination, at least.

Amanieu · 2025-12-09T10:41:04Z

I'm happy to land this as it is for now (with scalable vectors being Sized) so we can start working on the library side of SVE. But it's something we should keep in mind for the future.

davidtwco · 2025-12-09T12:45:52Z

The main advantage of making SVE vectors fully unsized is that it allows us to reliably determine, before monomorphization, whether the signature of a function has SVE locals, parameters or return values.

Maybe I'm missing something, but how does making the vectors fully unsized let us determine that? You can still write generic functions that can be instantiated by fully unsized types:

#![feature(extern_types)]
#![feature(sized_hierarchy)]
use std::marker::PointeeSized;

unsafe extern "C" {
    type Bar;
    
    fn get_bar() -> &'static Bar;
}

fn foo<T: PointeeSized>(x: &T) {}

fn main() {
    foo::<Bar>(unsafe { get_bar() });
}

In this example, Bar is an extern type because those exist today but it could be a SVE type and we wouldn't be able to know pre-mono whether the signature of foo will be instantiated with SVE type Bar.

The other disadvantage of making them fully unsized is that they can't be locals or return types or implement Copy without lots of special-casing (as this requires Sized today), and as they're just values in registers, they ought to be able to do those things.

I've been thinking of the sizedness of these types as a distinct problem from what we do about streaming-vs-non-streaming and all of the issues related to these types needing the SVE target feature. If they are non-const Sized, then we can make these locals/return types/Copy and that improves their usability within functions. Irrespective of their sizedness, we can still argue that they need to be special-cased to prevent generic instantiation, so that we can enforce the streaming/non-streaming boundary and anything else we need, or if we can think of a better solution then we can do that instead.

davidtwco · 2025-12-09T12:52:58Z

Oh, I understand now what you meant by making the types fully unsized enabling us to determine whether there are locals, parameters or return types: because the generic parameter won't implement Sized and the compiler will require that for the locals, parameters or return types, not that it will somehow let us prevent the instantiation of generic functions more generally for those types.

Nevertheless, I think my point is still the same, that we could make them non-const Sized and usable as locals and return types in SVE-enabled functions, and consider the limitations on generic instantiation a separate thing, giving us a bit more usability.

Extend parsing of `ReprOptions` with `rustc_scalable_vector(N)` which optionally accepts a single literal integral value - the base multiple of lanes that are in a scalable vector. Can only be applied to structs. Co-authored-by: Jamie Cunliffe <[email protected]>

Extend well-formedness checking and HIR analysis to prohibit the use of scalable vectors in structs, enums, unions, tuples and arrays. LLVM does not support scalable vectors being members of other types, so these restrictions are necessary. Co-authored-by: Jamie Cunliffe <[email protected]>

rustbot · 2025-12-09T13:58:01Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Introduces `BackendRepr::ScalableVector` corresponding to scalable vector types annotated with `repr(scalable)` which lowers to a scalable vector type in LLVM. Co-authored-by: Jamie Cunliffe <[email protected]>

LLVM doesn't handle stores on `<vscale x N x i1>` for `N != 16`, a type used internally in SVE intrinsics. Spilling to the stack to create debuginfo will cause errors during instruction selection. These types that are an internal implementation detail to the intrinsic, so users should never see them types and won't need any debuginfo. Co-authored-by: Jamie Cunliffe <[email protected]>

Scalable vectors cannot be members of ADTs and thus cannot be kept over await points in async functions.

Scalable vector types only work with the relevant target features enabled, so require this for any function with the types in its signature.

workingjubilee · 2025-12-09T20:55:56Z

It's also unclear whether we will ever be able to enable the compiler to have more ambiguously-sized argument and return types in the future. I think we eventually will want to explicitly ban what we want to ban rather than relying on some other element of the language "doing it for us". If nothing else, for the sake of producing a better error message, at least. That doesn't have to be addressed here, obviously.

workingjubilee · 2025-12-09T21:04:02Z

compiler/rustc_public/src/abi.rs

+            // FIXME(rustc_scalable_vector): Scalable vectors are `Sized` while the
+            // `sized_hierarchy` feature is not yet fully implemented. After `sized_hierarchy` is
+            // fully implemented, scalable vectors will remain `Sized`, they just won't be
+            // `const Sized` - whether `is_unsized` continues to return `true` at that point will


Suggested change

// `const Sized` - whether `is_unsized` continues to return `true` at that point will

// `const Sized` - whether `is_unsized` continues to return `false` at that point will

workingjubilee · 2025-12-09T21:08:37Z

compiler/rustc_target/src/callconv/x86_win64.rs

                // FIXME(eddyb) there should be a size cap here
                // (probably what clang calls "illegal vectors").
            }
+            BackendRepr::ScalableVector { .. } => unreachable!("scalable vectors are unsupported"),


I can guess why you used panic in one case and unreachable in the other, but I'd prefer it was consistent in either direction.

Suggested change

BackendRepr::ScalableVector { .. } => unreachable!("scalable vectors are unsupported"),

BackendRepr::ScalableVector { .. } => panic!("scalable vectors are unsupported"),

workingjubilee · 2025-12-09T21:08:45Z

compiler/rustc_target/src/callconv/x86.rs

                        false
                    }
+                    BackendRepr::ScalableVector { .. } => {
+                        unreachable!("scalable vectors are unsupported")


Suggested change

unreachable!("scalable vectors are unsupported")

panic!("scalable vectors are unsupported")

workingjubilee · 2025-12-09T21:22:13Z

compiler/rustc_abi/src/lib.rs

+    /// `N` in `rustc_scalable_vector(N)` - the element count of the scalable vector
+    ElementCount(u128),


This can just be u64. We will only parse 0..=u64::MAX and we will reject with an error things larger than 2.pow(16).

I feel almost like we should say "factor" instead of "count" since the "actual count" is unknown until runtime but uses the N provided here as a factor, but then syntactically the count is whatever was given in the attribute, but then... anyway, either is good.

workingjubilee · 2025-12-09T21:44:54Z

tests/ui/scalable-vectors/illformed-element-type.rs

+
+#[rustc_scalable_vector(2)]
+struct TyConstPtr(*const u8);
+//~^ ERROR: element type of a scalable vector must be a primitive scalar


The full error is here:

error: element type of a scalable vector must be a primitive scalar --> $DIR/illformed-element-type.rs:19:1 | LL | struct TyConstPtr(*const u8); | ^^^^^^^^^^^^^^^^^ | = help: only `u*`, `i*`, `f*`, `*const`, `*mut` and `bool` types are accepted

This suggests that *const u8 would be accepted, but this is rejected. Either the help needs to be changed or the code in rustc needs to be changed.

workingjubilee · 2025-12-09T21:47:11Z

compiler/rustc_abi/src/callconv.rs

                }))
            }

+            BackendRepr::ScalableVector { .. } => Err(Heterogeneous),


This seems like the wrong answer, they should be definitionally homogeneous, but maybe it's because we produce incorrect code if we answer as homogeneous?

workingjubilee · 2025-12-09T21:53:38Z

compiler/rustc_hir/src/attrs/data_structures.rs

+    RustcScalableVector {
+        /// The base multiple of lanes that are in a scalable vector, if provided. `element_count`
+        /// is not provided for representing tuple types.
+        element_count: Option<Box<u128>>,


Same comment from earlier about only having a u64 here anyways.

Since we will reject starting around 65536 we could also constrain further to u32. That might let us potentially avoid finagling boxes.

workingjubilee · 2025-12-09T22:01:56Z

compiler/rustc_codegen_ssa/src/mir/debuginfo.rs

+                // and casts it to a `svbool4_t`/`<vscale x 4 x i1>`. Therefore, it's important that
+                // the `<vscale x 4 x i32>` never spills because that'll cause errors during
+                // instruction selection. Spilling to the stack to create debuginfo for these


fascinating. because the corresponding <vscale x 4 x i1> predicate vector might also be spilled as a result of the <vscale x 4 x i32> vector being spilled?

workingjubilee · 2025-12-09T22:08:39Z

compiler/rustc_hir_analysis/src/check/wfcheck.rs

+                if matches!(ty.kind(), ty::Adt(def, _) if def.repr().scalable())
+                    && !matches!(adt_def.repr().scalable, Some(ScalableElt::Container))
+                {
+                    // Scalable vectors can only be fields of structs if the type has an


Sometimes I feel like I use typo nits as "have I read this?" markers, because the default Viewed checkbox hides the file... I often want to go back and cross-reference.

Suggested change

// Scalable vectors can only be fields of structs if the type has an

// Scalable vectors can only be fields of structs if the type has a

workingjubilee · 2025-12-09T22:13:10Z

compiler/rustc_target/src/callconv/loongarch.rs

+        BackendRepr::SimdVector { .. } => {
+            return Err(CannotUseFpConv);
+        }
+        BackendRepr::ScalableVector { .. } => unreachable!(),


Suggested change

BackendRepr::ScalableVector { .. } => unreachable!(),

BackendRepr::ScalableVector { .. } => panic!("scalable vectors are unsupported"),

workingjubilee · 2025-12-09T22:24:09Z

tests/ui/scalable-vectors/wellformed.rs

+#[rustc_scalable_vector]
+struct ScalableTuple(ScalableU8, ScalableU8, ScalableU8);


Is the recursively nested composition case of ScalableTupleTuple also wellformed? I didn't catch it in the illformed cases.

workingjubilee · 2025-12-10T04:06:17Z

That last scan-through should be all, unless something is revealed (made apparent?) by the next iteration, so

@rustbot author

rustbot assigned compiler-errors Jul 14, 2025

davidtwco mentioned this pull request Jul 14, 2025

Support for a scalable simd representation #118917

Closed

davidtwco marked this pull request as draft July 14, 2025 11:21

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 14, 2025

davidtwco force-pushed the sve-infrastructure branch 2 times, most recently from cf9474d to d58c634 Compare July 14, 2025 11:53

This comment was marked as resolved.

Sign in to view

davidtwco force-pushed the sve-infrastructure branch 2 times, most recently from 0c22701 to 3ad0898 Compare July 14, 2025 12:12

This comment has been minimized.

Sign in to view

davidtwco force-pushed the sve-infrastructure branch from 5c92874 to 3edf1b6 Compare July 14, 2025 13:30

This comment has been minimized.

Sign in to view

davidtwco force-pushed the sve-infrastructure branch from 3edf1b6 to 4f6b823 Compare July 14, 2025 14:20

workingjubilee requested changes Jul 14, 2025

View reviewed changes

rustbot assigned workingjubilee and unassigned compiler-errors Jul 14, 2025

This comment was marked as outdated.

Sign in to view

workingjubilee reviewed Dec 8, 2025

View reviewed changes

workingjubilee self-requested a review December 8, 2025 11:24

davidtwco and others added 2 commits December 9, 2025 13:45

davidtwco force-pushed the sve-infrastructure branch from 6cdc8f7 to d8b3d28 Compare December 9, 2025 13:57

This comment has been minimized.

Sign in to view

davidtwco and others added 4 commits December 9, 2025 14:47

codegen: implement repr(scalable)

d28929f

Introduces `BackendRepr::ScalableVector` corresponding to scalable vector types annotated with `repr(scalable)` which lowers to a scalable vector type in LLVM. Co-authored-by: Jamie Cunliffe <[email protected]>

mir_transform: prohibit scalable vectors in async

004812e

Scalable vectors cannot be members of ADTs and thus cannot be kept over await points in async functions.

mono: require target feature for scalable vectors

6a9fb63

Scalable vector types only work with the relevant target features enabled, so require this for any function with the types in its signature.

davidtwco force-pushed the sve-infrastructure branch from d8b3d28 to 6a9fb63 Compare December 9, 2025 14:47

workingjubilee reviewed Dec 9, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 10, 2025

		// FIXME(repr_scalable): Scalable vectors are `Sized` while the `sized_hierarchy`
		// feature is not yet fully implemented

	// `const Sized` - whether `is_unsized` continues to return `true` at that point will
	// `const Sized` - whether `is_unsized` continues to return `false` at that point will

	BackendRepr::ScalableVector { .. } => unreachable!("scalable vectors are unsupported"),
	BackendRepr::ScalableVector { .. } => panic!("scalable vectors are unsupported"),

	unreachable!("scalable vectors are unsupported")
	panic!("scalable vectors are unsupported")

		/// `N` in `rustc_scalable_vector(N)` - the element count of the scalable vector
		ElementCount(u128),

	// Scalable vectors can only be fields of structs if the type has an
	// Scalable vectors can only be fields of structs if the type has a

		#[rustc_scalable_vector]
		struct ScalableTuple(ScalableU8, ScalableU8, ScalableU8);

Uh oh!

rustc_scalable_vector(N) #143924

Are you sure you want to change the base?

rustc_scalable_vector(N) #143924

Conversation

davidtwco commented Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 14, 2025

Uh oh!

rustbot commented Jul 14, 2025

Uh oh!

davidtwco commented Jul 14, 2025

Uh oh!

This comment was marked as resolved.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

workingjubilee left a comment

Choose a reason for hiding this comment

Uh oh!

davidtwco commented Jul 14, 2025

Uh oh!

workingjubilee commented Jul 14, 2025

Uh oh!

This comment was marked as outdated.

workingjubilee 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Amanieu commented Dec 8, 2025

Uh oh!

programmerjake commented Dec 8, 2025

Uh oh!

workingjubilee commented Dec 8, 2025

Uh oh!

workingjubilee commented Dec 8, 2025

Uh oh!

workingjubilee commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Amanieu commented Dec 9, 2025

Uh oh!

Amanieu commented Dec 9, 2025

Uh oh!

workingjubilee commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Amanieu commented Dec 9, 2025

Uh oh!

davidtwco commented Dec 9, 2025

Uh oh!

davidtwco commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Dec 9, 2025

Uh oh!

`rustc_scalable_vector(N)` #143924

`rustc_scalable_vector(N)` #143924

davidtwco commented Jul 14, 2025 •

edited

Loading

workingjubilee left a comment •

edited by rustbot

Loading

workingjubilee commented Dec 8, 2025 •

edited

Loading

workingjubilee commented Dec 9, 2025 •

edited

Loading

davidtwco commented Dec 9, 2025 •

edited

Loading

workingjubilee Dec 9, 2025 •

edited

Loading

workingjubilee Dec 9, 2025 •

edited

Loading

workingjubilee Dec 9, 2025 •

edited

Loading