Add an `implements!` macro which answers "does type X implement trait Y?".
Primarily this is useful in tests, but can also be used in macros to produce specialized code paths.
```rust
assert!(implements!(Ident: Send));
assert!(implements!(Ident: Sync));
assert!(implements!(Allocator: !Sync));
```
Also works in const context:
```rust
const U32_IS_COPY: bool = implements!(u32: Copy);
const _: () = assert!(U32_IS_COPY);
```
Particularly useful for checking that a type does _not_ implement a trait. Without this macro, that requires a `compile_fail` doctest, which is fragile - when code changes, the doctest can easily start failing for _different_ reasons, which means it's no longer testing what it's meant to, and there's no way to spot that.
This is a primitive required for forthcoming `MultiVec` SoA vec type. Putting it in `oxc_data_structures` as it can be useful in other places too.
Add a `const_str_eq` function to `oxc_data_structures`, which allows comparing two strings in const context.
```rust
const IS_SAME: bool = const_str_eq("foo", "bar");
const _: () = assert!(!IS_SAME);
```
This is a primitive required for forthcoming `MultiVec` SoA vec type. Putting it in `oxc_data_structures` as it can be useful in other places too.
Introduce a `StringExt` trait which adds 2 unsafe methods to `String`:
- `push_unchecked`
- `push_str_unchecked`
Both push to the string without checking there's sufficient capacity for it. The caller guarantees the push cannot cause the `String`'s length to exceed its capacity.
Both methods call the corresponding safe methods of `String` internally, with `assert_unchecked!`s preceding those calls to allow compiler to remove the bounds check. The shape of these assertions matches the code in `String`'s methods exactly.
Examination of generated assembly confirms that the optimizations work.
Most of our low-level data structures e.g. `Arena`, `Vec`, `Box`, and `Stack` types use `NonNull` pointers.
`NonNull` is fundamentally dangerous. A `NonNull` can be created from a `&T`, and so only has read permissions. Yet you can call `as_mut()` on such a pointer to gain a `&mut T`, and that's instant undefined behavior. The onus is on the author to manually track how pointers were created and so whether they have write permissions or not, to avoid this hazard.
In complex code like the arena allocator, pointers are created in various different places, stored in structs, and passed around, so it is not trivial to track their permissions, and neither the type system nor Clippy gives you any help.
In comparison, raw pointers `*const T` and `*mut T` *do* make such a distinction between read-only and write-enabled pointers, but they have other shortcomings - they lack the non-null guarantee of `NonNull` (which can improve perf in some cases), and `*mut T` is not covariant, so it is unsuitable for use in types like `Vec`.
This PR intoduces 2 new pointer types `NonNullConst` and `NonNullMut`. Both are just wrappers around `NonNull` and are equivalent to `NonNull` at runtime. What they add is type system-level guarantees of the read/write permissions that these pointers have. i.e. they bring together the const/mut distinction of raw `*const` / `*mut` pointers, and the advantages of `NonNull`.
This PR only introduces these new pointer types, but does not use them in the codebase yet. It is my intention to migrate `Arena` allocator over to these new pointer types, to make it harder to blunder into causing UB while reworking the implementation. Other types like `Vec`, `Box`, `Stack`, and lexer's `Source` could also be migrated over later on.
Add a `fieldless_enum!` macro. This macro generates a `VARIANTS` constant on the type that lists all the enum's variants.
```rs
fieldless_enum! {
enum Foo {
A,
B,
C,
}
}
assert_eq!(Foo::VARIANTS, [Foo::A, Foo::B, Foo::C]);
```
This is useful for code which interacts with the enum, and needs to take some action on each variant.
Add `boxed_slice!` and `boxed_array!` macros, similar to std lib's `vec!` macro.
```rs
// Box<[u64]>
let box_slice = boxed_slice![0u64; 10];
// Box<[u64; 10]>
let box_array = boxed_array![0u64; 10];
```
Use `boxed_array!` in linter to shorten code.
These macros could probably be made more efficient by using `MaybeUninit` and emplacement, but can leave that until later.
`PointerExt` trait was introduced to allow using `NonNull::offset_from_unsigned` (and similar APIs) on Rust v1.87.0 and above, without breaking code on earlier Rust versions where these APIs did not exist.
Our MSRV is now v1.87.0 (#12900), so we can just use these methods directly, and `PointerExt` is not required any more. Remove it.
overlookmotel