| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Stabilize `slice_first_last_chunk`
This PR does a few different things based around stabilizing `slice_first_last_chunk`. They are split up so this PR can be by-commit reviewed, I can move parts to a separate PR if desired.
This feature provides a very elegant API to extract arrays from either end of a slice, such as for parsing integers from binary data.
## Stabilize `slice_first_last_chunk`
ACP: https://github.com/rust-lang/libs-team/issues/69
Implementation: https://github.com/rust-lang/rust/issues/90091
Tracking issue: https://github.com/rust-lang/rust/issues/111774
This stabilizes the functionality from https://github.com/rust-lang/rust/issues/111774:
```rust
impl [T] {
pub const fn first_chunk<const N: usize>(&self) -> Option<&[T; N]>;
pub fn first_chunk_mut<const N: usize>(&mut self) -> Option<&mut [T; N]>;
pub const fn last_chunk<const N: usize>(&self) -> Option<&[T; N]>;
pub fn last_chunk_mut<const N: usize>(&mut self) -> Option<&mut [T; N]>;
pub const fn split_first_chunk<const N: usize>(&self) -> Option<(&[T; N], &[T])>;
pub fn split_first_chunk_mut<const N: usize>(&mut self) -> Option<(&mut [T; N], &mut [T])>;
pub const fn split_last_chunk<const N: usize>(&self) -> Option<(&[T], &[T; N])>;
pub fn split_last_chunk_mut<const N: usize>(&mut self) -> Option<(&mut [T], &mut [T; N])>;
}
```
Const stabilization is included for all non-mut methods, which are blocked on `const_mut_refs`. This change includes marking the trivial function `slice_split_at_unchecked` const-stable for internal use (but not fully stable).
## Remove `split_array` slice methods
Tracking issue: https://github.com/rust-lang/rust/issues/90091
Implementation: https://github.com/rust-lang/rust/pull/83233#pullrequestreview-780315524
This PR also removes the following unstable methods from the `split_array` feature, https://github.com/rust-lang/rust/issues/90091:
```rust
impl<T> [T] {
pub fn split_array_ref<const N: usize>(&self) -> (&[T; N], &[T]);
pub fn split_array_mut<const N: usize>(&mut self) -> (&mut [T; N], &mut [T]);
pub fn rsplit_array_ref<const N: usize>(&self) -> (&[T], &[T; N]);
pub fn rsplit_array_mut<const N: usize>(&mut self) -> (&mut [T], &mut [T; N]);
}
```
This is done because discussion at #90091 and its implementation PR indicate a strong preference for nonpanicking APIs that return `Option`. The only difference between functions under the `split_array` and `slice_first_last_chunk` features is `Option` vs. panic, so remove the duplicates as part of this stabilization.
This does not affect the array methods from `split_array`. We will want to revisit these once `generic_const_exprs` is further along.
## Reverse order of return tuple for `split_last_chunk{,_mut}`
An unresolved question for #111774 is whether to return `(preceding_slice, last_chunk)` (`(&[T], &[T; N])`) or the reverse (`(&[T; N], &[T])`), from `split_last_chunk` and `split_last_chunk_mut`. It is currently implemented as `(last_chunk, preceding_slice)` which matches `split_last -> (&T, &[T])`. The first commit changes these to `(&[T], &[T; N])` for these reasons:
- More consistent with other splitting methods that return multiple values: `str::rsplit_once`, `slice::split_at{,_mut}`, `slice::align_to` all return tuples with the items in order
- More intuitive (arguably opinion, but it is consistent with other language elements like pattern matching `let [a, b, rest @ ..] ...`
- If we ever added a varidic way to obtain multiple chunks, it would likely return something in order: `.split_many_last::<(2, 4)>() -> (&[T], &[T; 2], &[T; 4])`
- It is the ordering used in the `rsplit_array` methods
I think the inconsistency with `split_last` could be acceptable in this case, since for `split_last` the scalar `&T` doesn't have any internal order to maintain with the other items.
## Unresolved questions
Do we want to reserve the same names on `[u8; N]` to avoid inference confusion? https://github.com/rust-lang/rust/pull/117561#issuecomment-1793388647
---
`slice_first_last_chunk` has only been around since early 2023, but `split_array` has been around since 2021.
`@rustbot` label -T-libs +T-libs-api -T-libs +needs-fcp
cc `@rust-lang/wg-const-eval,` `@scottmcm` who raised this topic, `@clarfonthey` implementer of `slice_first_last_chunk` `@jethrogb` implementer of `split_array`
Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Stabilizing.20array-from-slice.20*something*.3F
Fixes: #111774
|
|
This stabilizes all methods under `slice_first_last_chunk`.
Additionally, it const stabilizes the non-mut functions and moves the `_mut`
functions under `const_slice_first_last_chunk`. These are blocked on
`const_mut_refs`.
As part of this change, `slice_split_at_unchecked` was marked const-stable for
internal use (but not fully stable).
|
|
This removes emit_enum_variant and the emit_usize calls that resulted
in. In libcore this eliminates 17% of leb128, taking us from 8964488 to
7383842 leb128's serialized.
|
|
|
|
|
|
|
|
- Sort dependencies and features sections.
- Add `tidy` markers to the sorted sections so they stay sorted.
- Remove empty `[lib`] sections.
- Remove "See more keys..." comments.
Excluded files:
- rustc_codegen_{cranelift,gcc}, because they're external.
- rustc_lexer, because it has external use.
- stable_mir, because it has external use.
|
|
|
|
It's hyper-optimized, we don't need our own unsafe code here.
This requires getting rid of all the `Allocator` stuff, which isn't
needed anyway.
|
|
Making them consistent with similar impls.
|
|
|
|
`serialize.rs` has the `Encodable`/`Decodable` impls for lots of basic
types, including `Vec`. `collection_impls` has it for lots of collection
types. The distinction isn't really meaningful, and it's simpler to have
them all in a single file.
|
|
|
|
I.e. `maybe_uninit_slice` and `new_uninit`.
Also sort the remaining features and remove an ugly, low-value comment.
|
|
|
|
|
|
|
|
|
|
The new version was already added to the tree as an indirect dependency
in #113046, but now our direct dependents are using it too.
|
|
It allows a variable size, but in practice we always use the default of
8192 bytes. This commit fixes it to that size, which makes things
slightly faster because the size can be hard-wired in generated code.
The commit also:
- Rearranges some buffer capacity checks so they're all in the same form
(`x > BUFSIZE`).
- Removes some buffer capacity assertions and comments about them. With
an 8192 byte buffer, we're not in any danger of overflowing a `usize`.
|
|
Make them generate the entire function, not just the function body.
|
|
`MemEncoder` was recently removed, leaving `FileEncoder` as the only
encoder. So this prefix is no longer needed, and `write_leb128!` matches
the existing `read_leb128!`.
|
|
So they match the order in the `Decoder` trait.
|
|
|
|
It's only used in tests. Which is bad, because it means that
`FileEncoder` is used in the compiler but isn't used in tests!
`tests/opaque.rs` now tests encoding/decoding round-trips via file.
Because this is slower than memory, this commit also adjusts the
`u16`/`i16` tests so they are more like the `u32`/`i32` tests, i.e. they
don't test every possible value.
|
|
Round-trip encoding/decoding of many types is tested in
`compiler/rustc_serialize/tests/opaque.rs`. There is also a small amount
of encoding/decoding testing in three files in `tests/ui-fulldeps`.
There is no obvious reason why these three files are necessary. They
were originally added in 2014. Maybe it wasn't possible for a proc
macro to run in a unit test back then?
This commit just moves the testing from those three files into the unit
test.
|
|
It's just a synonym for `read_u8`.
|
|
The methods for `i8`, `bool`, `char`, `str` are the same for all impls,
because they layered on top of other methods.
|
|
Checking that `read_raw_bytes(len)` changes the position by `len` is a
reasonable thing for a test, but isn't much use in just one of the
zillion `Decodable` impls.
|
|
Because I was wondering about it, and this may save a future person from
also wondering.
|
|
It's unnecessary. Note that `MemDecoder::read_raw_bytes` how has a `&'a
[u8]` return type, the same as what `read_raw_bytes_inherent` had.
|
|
|
|
|
|
|
|
|
|
Use `ThinVec` more in the AST
r? `@ghost`
|
|
Because 0.2.10 added supports for `ThinVec::splice`, and 0.2.12 is the
latest release.
|
|
it looks like Encodable was fallible at some point, but that was changed
which means that this FIXME is no longer applicable
|
|
|
|
|
|
|
|
|
|
|
|
|
|
isikkema:fix-zmeta-stats-file-encoder-no-read-perms, r=isikkema
Fix -Zmeta-stats ICE by giving `FileEncoder` file read permissions
Fixes #101001
As far as I can tell, #101001 is caused because the file is being created with write-only permissions here: https://github.com/rust-lang/rust/blob/master/compiler/rustc_serialize/src/opaque.rs#L196
but it is trying to be read here: https://github.com/rust-lang/rust/blob/master/compiler/rustc_metadata/src/rmeta/encoder.rs#L780
This PR attempts to fix this by creating/opening the file with the same permissions as `File::create()` with the addition of read.
|
|
|
|
On later stages, the feature is already stable.
Result of running:
rg -l "feature.let_else" compiler/ src/librustdoc/ library/ | xargs sed -s -i "s#\\[feature.let_else#\\[cfg_attr\\(bootstrap, feature\\(let_else\\)#"
|
|
`rustc_data_structures::thin_vec::ThinVec` looks like this:
```
pub struct ThinVec<T>(Option<Box<Vec<T>>>);
```
It's just a zero word if the vector is empty, but requires two
allocations if it is non-empty. So it's only usable in cases where the
vector is empty most of the time.
This commit removes it in favour of `thin_vec::ThinVec`, which is also
word-sized, but stores the length and capacity in the same allocation as
the elements. It's good in a wider variety of situation, e.g. in enum
variants where the vector is usually/always non-empty.
The commit also:
- Sorts some `Cargo.toml` dependency lists, to make additions easier.
- Sorts some `use` item lists, to make additions easier.
- Changes `clean_trait_ref_with_bindings` to take a
`ThinVec<TypeBinding>` rather than a `&[TypeBinding]`, because this
avoid some unnecessary allocations.
|
|
|
|
use a custom allocator
|
