Add experimental `fallible::FallibleVec` - #157394

ChrisDenton · 2026-06-03T18:45:06Z

Tracking issue: #157392

There are a few things to be aware of here:

This is still experimental. It might be removed at any time so we have to be careful about any interdependency between this and Vec
Vec is a pretty crucial part of rust's standard library. We have to be extremely careful touching its code. We might regress performance or make debugging worse.

With that in mind, this PR does the minimum necessary for an MVP fallible::FallibleVec. The only actually new thing it adds is fallible push and push_mut methods. The rest just forwards to Vec equivalents. Further APIs can be added (carefully) afterwards.

I apologise for the number of lines changed in the PR but they are mostly copy/pasted docs (I wanted them for the testable examples mostly). We should probably find a better way of duplicating them but I think this works for a minimally intrusive experiment.

rustbot · 2026-06-03T18:45:11Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: libs
libs expanded to 8 candidates
Random selection from Mark-Simulacrum, jhpratt

ChrisDenton · 2026-06-03T22:54:45Z

 -	   = note: multiple `impl`s satisfying `Vec<_>: aux::Trait` found in the `unstable_impl_method_selection_aux` crate:
 -	           - impl aux::Trait for Vec<u32>;
 -	           - impl aux::Trait for Vec<u64>
 +	   = note: multiple `impl`s satisfying `std::vec::Vec<_>: aux::Trait` found in the `unstable_impl_method_selection_aux` crate:
 +	           - impl aux::Trait for std::vec::Vec<u32>;
 +	           - impl aux::Trait for std::vec::Vec<u64>

Ooph, that's unfortunate. Simplest thing is to rename this type. But I do wonder if that could be fixed.

Mark-Simulacrum · 2026-06-21T18:17:22Z

Let me know if this is actually waiting on a review -- for now since CI is failing I'll move it back to waiting on author.

rustbot · 2026-09-16T14:32:57Z

Any special-casing of Miri in the standard library requires review.

cc @rust-lang/miri

ChrisDenton · 2026-09-16T21:41:35Z

@Mark-Simulacrum sorry about the wait, I have more time to move this forward now. As a reminder to myself as much as you the naming "FallibleVec" is pretty much like "yeet", it's probably not what we end up with but it can act as a placeholder until we figure out that particular bikeshed. Also diagnostics need some work, but I'm told this isn't trivial so I'd rather that not be a blocker atm. As noted in the OP, this is intended to be a MVP. It's likely everything about this API will be argued over but I think we should start with something rather than wait until we've fully designed everything.

@rustbot ready

rustbot · 2026-09-16T23:18:38Z

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.

ChrisDenton · 2026-09-16T23:21:19Z

I removed the Allocator API stuff. When I originally made this PR it had been more or less unchanged for ages but now it's had a lot of work done and is nearing stabilization so I want to avoid stepping on any toes. It's easy to add back the Allocator methods in a follow up PR once Allocator is properly stable and things have settled a bit.

Mark-Simulacrum

r=me with some nits fixed (or if you want to make more extensive changes then we can do more review)

View changes since this review

Mark-Simulacrum · 2026-09-19T19:33:03Z

+#[unstable(feature = "fallible_vec", issue = "157392")]
+#[derive(Debug, Hash, Eq, PartialEq, Ord, PartialOrd)]
+pub struct FallibleVec<T> {
+    buf: InfallibleVec<T>,


Hm, do you think the code is more readable with this called InfallibleVec vs. just Vec?

Mark-Simulacrum · 2026-09-19T19:34:25Z

+/// All allocating methods will return [`AllocError`][super::AllocError] if allocation fails.
+/// Otherwise are the same as their infallible `Vec` counterparts.
+///
+/// Both `fallible::Vec` and `Vec` are fully ABI compatible, which means you can freely cast between with no cost.


Suggested change

/// Both `fallible::Vec` and `Vec` are fully ABI compatible, which means you can freely cast between with no cost.

/// Both `fallible::Vec<T>` and `Vec<T>` are fully layout and ABI compatible, which means you can freely cast between the two.

Mark-Simulacrum · 2026-09-19T19:35:49Z

+    /// # Safety
+    ///
+    /// This is highly unsafe, due to the number of invariants that aren't
+    /// checked:


I think it would be nice to find a way to not duplicate all of the safety requirements, code examples, etc. -- maybe it makes sense to just forward to main Vec docs here and in other methods?

I think at least right now most users should understand this type as being "equivalent to" Vec, modulo some specific details, and having all the docs duplicated makes it harder to find those differences.

I see you noted this in the PR description -- ultimately happy to defer this but I think it'll continue being a painpoint until/after stabilization of this API surface area since we'll keep forgetting to update both places (or need to review duplicate diffs).

Mark-Simulacrum · 2026-09-19T19:37:56Z

+    #[rustc_const_unstable(feature = "fallible_vec", issue = "157392")]
+    pub const fn to_fallible(self) -> FallibleVec<T> {
+        FallibleVec { buf: self }
+    }


Should we provide conversions over &mut self and &self? I think we can transmute those references too, right?

Mark-Simulacrum · 2026-09-19T20:03:18Z

+    /// ```
+    #[inline]
+    pub fn leak<'a>(self) -> &'a mut [T]
+where {


nit: bad formatting

Mark-Simulacrum · 2026-09-19T20:07:56Z

+    /// vector's elements to a larger allocation. This expensive operation is
+    /// offset by the *capacity* *O*(1) insertions it allows.
+    #[inline]
+    #[must_use = "if you don't need a reference to the value, use `Vec::push` instead"]


nit: InfallibleVec::push

Mark-Simulacrum · 2026-09-19T20:08:51Z

+    /// As of Rust 1.57, this method does not reallocate or shrink the `FallibleVec`,
+    /// so the leaked allocation may include unused capacity that is not part
+    /// of the returned slice.


nit: FallibleVec would nead to make this decision prior to stabilization, since the return type would be different.

Mark-Simulacrum · 2026-09-19T20:10:40Z

+
+    #[inline]
+    fn deref(&self) -> &[T] {
+        self.as_slice()


I suspect the structure of this method is going to end up invalidating pointers that Vec wouldn't have? Or do we get away with it in practice? (Haven't thought too deeply about this and doesn't really block landing this, but probably worth adding to tracking issue until we have an answer)

(Specifically any guarantees or happens-to-work around e.g. spare capacity not getting invalidated when calling len())

Mark-Simulacrum · 2026-09-19T20:13:43Z

    }
+
+    /// A specialized version of `self.reserve(len, 1)` which requires the
+    /// caller to ensure `len == self.capacity()`.


Hm, this wording suggests unsafe fn is warranted, but I guess it's pre-existing either way?

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 3, 2026

rustbot assigned Mark-Simulacrum Jun 3, 2026