pub struct Vec<'alloc, T>(/* private fields */);
Expand description
A Vec
without Drop
, which stores its data in the arena allocator.
§No Drop
s
Objects allocated into Oxc memory arenas are never Dropped
. Memory is released in bulk
when the allocator is dropped, without dropping the individual objects in the arena.
Therefore, it would produce a memory leak if you allocated Drop
types into the arena
which own memory allocations outside the arena.
Static checks make this impossible to do. Vec::new_in
and all other methods which create
a Vec
will refuse to compile if called with a Drop
type.
Implementations§
Source§impl<'alloc, T> Vec<'alloc, T>
impl<'alloc, T> Vec<'alloc, T>
Sourcepub fn new_in(allocator: &'alloc Allocator) -> Self
pub fn new_in(allocator: &'alloc Allocator) -> Self
Constructs a new, empty Vec<T>
.
The vector will not allocate until elements are pushed onto it.
§Examples
use oxc_allocator::{Allocator, Vec};
let arena = Allocator::default();
let mut vec: Vec<i32> = Vec::new_in(&arena);
assert!(vec.is_empty());
Sourcepub fn with_capacity_in(capacity: usize, allocator: &'alloc Allocator) -> Self
pub fn with_capacity_in(capacity: usize, allocator: &'alloc Allocator) -> Self
Constructs a new, empty Vec<T>
with at least the specified capacity
with the provided allocator.
The vector will be able to hold at least capacity
elements without
reallocating. This method is allowed to allocate for more elements than
capacity
. If capacity
is 0, the vector will not allocate.
It is important to note that although the returned vector has the minimum capacity specified, the vector will have a zero length.
For Vec<T>
where T
is a zero-sized type, there will be no allocation
and the capacity will always be u32::MAX
.
§Panics
Panics if the new capacity exceeds isize::MAX
bytes.
§Examples
use oxc_allocator::{Allocator, Vec};
let arena = Allocator::default();
let mut vec = Vec::with_capacity_in(10, &arena);
// The vector contains no items, even though it has capacity for more
assert_eq!(vec.len(), 0);
assert_eq!(vec.capacity(), 10);
// These are all done without reallocating...
for i in 0..10 {
vec.push(i);
}
assert_eq!(vec.len(), 10);
assert_eq!(vec.capacity(), 10);
// ...but this may make the vector reallocate
vec.push(11);
assert_eq!(vec.len(), 11);
assert!(vec.capacity() >= 11);
// A vector of a zero-sized type will always over-allocate, since no
// allocation is necessary
let vec_units = Vec::<()>::with_capacity_in(10, &arena);
assert_eq!(vec_units.capacity(), usize::MAX);
Sourcepub fn from_iter_in<I: IntoIterator<Item = T>>(
iter: I,
allocator: &'alloc Allocator,
) -> Self
pub fn from_iter_in<I: IntoIterator<Item = T>>( iter: I, allocator: &'alloc Allocator, ) -> Self
Create a new Vec
whose elements are taken from an iterator and
allocated in the given allocator
.
This is behaviorially identical to FromIterator::from_iter
.
Sourcepub fn from_array_in<const N: usize>(
array: [T; N],
allocator: &'alloc Allocator,
) -> Self
pub fn from_array_in<const N: usize>( array: [T; N], allocator: &'alloc Allocator, ) -> Self
Create a new Vec
from a fixed-size array, allocated in the given allocator
.
This is preferable to from_iter_in
where source is an array, as size is statically known,
and compiler is more likely to construct the values directly in arena, rather than constructing
on stack and then copying to arena.
§Examples
use oxc_allocator::{Allocator, Vec};
let allocator = Allocator::default();
let array: [u32; 4] = [1, 2, 3, 4];
let vec = Vec::from_array_in(array, &allocator);
Sourcepub fn into_boxed_slice(self) -> Box<'alloc, [T]>
pub fn into_boxed_slice(self) -> Box<'alloc, [T]>
Trait Implementations§
Source§impl<'new_alloc, T, C> CloneIn<'new_alloc> for Vec<'_, T>where
T: CloneIn<'new_alloc, Cloned = C>,
C: 'new_alloc,
impl<'new_alloc, T, C> CloneIn<'new_alloc> for Vec<'_, T>where
T: CloneIn<'new_alloc, Cloned = C>,
C: 'new_alloc,
Source§fn clone_in(&self, allocator: &'new_alloc Allocator) -> Self::Cloned
fn clone_in(&self, allocator: &'new_alloc Allocator) -> Self::Cloned
self
into the given allocator
. allocator
may be the same one
that self
is already in.Source§fn clone_in_with_semantic_ids(
&self,
allocator: &'new_alloc Allocator,
) -> Self::Cloned
fn clone_in_with_semantic_ids( &self, allocator: &'new_alloc Allocator, ) -> Self::Cloned
clone_in
, but for some special type, it will also clone the semantic ids.
Please use this method only if you make sure semantic info is synced with the ast node.Source§impl<'i, T> IntoIterator for &'i Vec<'_, T>
impl<'i, T> IntoIterator for &'i Vec<'_, T>
Source§impl<'i, T> IntoIterator for &'i mut Vec<'_, T>
impl<'i, T> IntoIterator for &'i mut Vec<'_, T>
Source§impl<'alloc, T> IntoIterator for Vec<'alloc, T>
impl<'alloc, T> IntoIterator for Vec<'alloc, T>
Source§impl<'a, T> TakeIn<'a> for Vec<'a, T>
impl<'a, T> TakeIn<'a> for Vec<'a, T>
Source§fn take_in<A: AllocatorAccessor<'a>>(&mut self, allocator_accessor: A) -> Self
fn take_in<A: AllocatorAccessor<'a>>(&mut self, allocator_accessor: A) -> Self
Source§fn take_in_box<A: AllocatorAccessor<'a>>(
&mut self,
allocator_accessor: A,
) -> Box<'a, Self>
fn take_in_box<A: AllocatorAccessor<'a>>( &mut self, allocator_accessor: A, ) -> Box<'a, Self>
impl<'alloc, T: Eq> Eq for Vec<'alloc, T>
impl<'alloc, T> StructuralPartialEq for Vec<'alloc, T>
impl<T: Sync> Sync for Vec<'_, T>
SAFETY: Even though Bump
is not Sync
, we can make Vec<T>
Sync
if T
is Sync
because:
-
No public methods allow access to the
&Bump
thatVec
contains (inRawVec
), so user cannot illegally obtain 2&Bump
s on different threads viaVec
. -
All internal methods which access the
&Bump
take a&mut self
.&mut Vec
cannot be transferred across threads, and nor can an ownedVec
(Vec
is notSend
). Therefore these methods taking&mut self
can be sure they’re not operating on aVec
which has been moved across threads.
Note: Vec
CANNOT be Send
, even if T
is Send
, because that would allow 2 Vec
s on different
threads to both allocate into same arena simultaneously. Bump
is not thread-safe, and this would
be undefined behavior.