resolve : mark repr_simd as internal
I changed ```repr_simd``` to ```internal``` and changed the position to ```feature-group-start: internal feature gates```.
closerust-lang/rust#154034
Remove string content from panics
String content can be useful for debugging panics, particularly when you are working on a small codebase where you can infer more about the path taken through your program based on the content of the string.
In production deployments that upload crashes for centralized debugging, string content poses a risk to user privacy. The string can accidentally contain information that the user is not expecting to share with the development team.
On balance it seems like the risks outweigh the benefits. It is easy to add a `dbg!()` statement to gather more information in development; but comparatively tricky to ensure panics are sanitized by every rust app that monitors their production deployments.
Ref https://internals.rust-lang.org/t/stop-including-string-content-in-index-panics/24067
r? @scottmcm
fixed VecDeque::splice() not filling the buffer correctly when resizing the buffer on start = end range
This PR fixesrust-lang/rust#151758. The issue came from `Splice::move_tail`, which as joboet pointed out:
> The issue is in move_tail, which resizes the buffer, but fails to account for the resulting hole.
The problem with reserving more space through `VecDeque`'s `buf.reserve()` is that it doesn't update `VecDeque`'s `head`, which means that this code in `move_tail`:
```rust
deque.wrap_copy(
deque.to_physical_idx(tail_start),
deque.to_physical_idx(new_tail_start),
self.tail_len,
);
```
could move over the section of data that `tail_start..tail_start + self.tail_len` of the buffer is supposed to be held at to the incorrect destination since all `.to_physical_idx()` is doing is a wrapping add on the `VecDeque`'s head with the passed in `idx` value.
To avoid this I decided to use `VecDeque::reserve` to both allocate more space into the `VecDeque` if necessary and update head appropriately. However, `VecDeque::reserve` internally relies on the `VecDeque`'s `len` field. Earlier in `VecDeque::splice`, it modifies the `VecDeque`'s `len` constructing the drain via `Drain::new` (as it does a `mem::replace` on `deque.len` with the start bound of the passed in `range`). The `VecDeque`'s `len` can also be potentially modified in the earlier `Splice::fill()` call if it does any replacement towards elements within the passed in `range` value for `VecDeque::splice()`. I needed to temporarily restore the `VecDeque`'s `len` to its actual len, so that `VecDeque::reserve` can work properly. Afterward, you can bring back the `VecDeque`'s `len` to what its value was before and fill the gap appropriately with the rest of the `replace_with` content.
r? @joboet
String content can be useful for debugging panics, particularly when you
are working on a small codebase where you can infer more about the path
taken through your program based on the content of the string.
In production deployments that upload crashes for centralized debugging,
string content poses a risk to user privacy. The string can accidentally
contain information that the user is not expecting to share with the
development team.
On balance it seems like the risks outweigh the benefits. It is easy to
add a `dbg!()` statement to gather more information in development; but
comparatively tricky to ensure panics are sanitized by every rust app
that monitors their production deployments.
Ref https://internals.rust-lang.org/t/stop-including-string-content-in-index-panics/24067
Allow `./x test` to run tests without doc tests and without benchmarks
# Problem
For Ferrocene we would like to run only the `coretests` and `alloctests` test suites when measuring code coverage. Running `corebenches` and `allocbenches` would alter the numbers, which is not compliant with the certification.
This is currently not possible in bootstrap. By default `./x test` runs unit, integration and doc tests. `./x test --doc` only runs doc tests. So far, so good.
The problem is that while `./x test --no-doc` stops bootstrap from executing doc tests, it surprisingly starts executing benchmarks (next to examples and bins as well). It basically behaves like `cargo test --all-targets`.
# Solution
This PR renames the existing `--no-doc` flag to `--all-targets` and keeps the same behaviour as before. Unfortunately it is not possible to internally switch from `cargo --bins --examples --tests --benches` to `cargo --all-targets` because it will fail e.g. `./x test library/alloc --all-targets` with an error like "use of unstable library feature `test`".
Additionally, this PR add a `./x test --tests` flag (equivalent to `cargo test --tests`) that only executes unit and integration tests.
Both changes we are doing in https://github.com/ferrocene/ferrocene anyways, but believe that they may be useful for other people as well and therefore would like to contribute them.
Note that this PR does _not_ change the behaviour of either `./x test` or `./x test --doc`.
## Note on `test = true`
While this change enables bootstrap to run tests without doc tests and without benchmarks, executing `./x test library/core library/alloc --tests` will still build and execute `corebenches` and `allocbenches`.
What?! 😱 Why all of this effort to enable it then?
Good question! The reason they are still executed is, that they are marked with `test = true` in their respective `Cargo.toml` ([corebenches](https://github.com/rust-lang/rust/blob/3f9853562c73af38a5e6af8b0da1b2734a327e19/library/coretests/Cargo.toml#L24), [allocbenches](https://github.com/rust-lang/rust/blob/3f9853562c73af38a5e6af8b0da1b2734a327e19/library/alloctests/Cargo.toml#L32)).
@bjorn3 mentioned that it is important for upstream that those benchmarks are executed by default, even if no `./x --all-targets` is passed. This is perfectly possible with this PR. Benchmarks marked with `test = true` will be executed when calling either of `./x test`, `./x test --tests` or `./x --all-targets`. Therefore this PR does not include a commit to change that. We will just do this change in https://github.com/ferrocene/ferrocene.
## Open questions
### Error message
I added one commit that adds an error message if a user passes `--no-doc` and points them to `--all-targets` and `--tests`. I think it might be nice to have, but if you think it is not necessary, I can remove it.
# How to test this change
You can see the change in action by running `./x test library/alloc --tests` and `./x test library/alloc --all-targets`. The first will execute `alloctests` and `allocbenches` (which is marked with `test = true`), while the second will additionally run `benches/vec_deque_append.rs` (which is _not_ marked with `test = true`).
- `./x run generate-completions`
- Search and replace `--no-doc` with `--all-targets`
This is to keep the behaviour the same.
- Document `./x test --tests` in `rustc-dev-guide`
- Add change info
`BTreeMap::merge` optimized
This is an optimized version of https://github.com/rust-lang/rust/pull/151981. See [ACP](https://github.com/rust-lang/libs-team/issues/739#issuecomment-3873487320) for more information on `BTreeMap::merge` does.
CC @programmerjake. Let me know what you think of how I'm using `CursorMut` and `IntoIter` here and whether the unsafe code here looks good. I decided to use `ptr::read()` and `ptr::write()` to grab the value from `CursorMut` as `V` than `&mut V`, use it within the `conflict` function, and overwrite the content of conflicting key afterward.
I know this needs some polishing, especially with refactoring some redundant looking code in a nicer way, some of which could probably just be public API methods for `CursorMut`. It does pass all the tests that I currently have for `BTreeMap::merge` (inspired from `BTreeMap::append`) though, so that's good.
Optimize indexing slices and strs with inclusive ranges
Instead of separately checking for `end == usize::MAX` and `end + 1 > slice.len()`, we can check for `end >= slice.len()`. Also consolidate all the str indexing related panic functions into a single function which reports the correct error depending on the arguments, as the slice indexing code already does.
The downside of all this is that the panic message is slightly less specific when trying to index with `[..=usize::MAX]`: instead of saying "attempted to index str up to maximum usize" it just says "end byte index {end} out of bounds". But this is a rare enough case that I think it is acceptable
The panic message when slicing a string with a negative length range (eg
`"abcdef"[4..3]`) is confusing: it gives the condition that failed to hold,
whilst all the other panic messages give the condition that did hold.
Before:
begin <= end (4 <= 3) when slicing `abcdef`
After:
begin > end (4 > 3) when slicing `abcdef`
Replace `self.end() == usize::MAX` and `self.end() + 1 > slice.len()`
with `self.end() >= slice.len()`. Same reasoning as previous commit.
Also consolidate the str panicking functions into function.
remove `#[deprecated]` from unstable & internal `SipHasher13` and `24` types
These types are unstable and `doc(hidden)` (under the internal feature `hashmap_internals`). Deprecating them only adds noise (`#[allow(deprecated)]`) to all places where they are used, so this PR removes the deprecation attributes from them.
It also includes a few other small cleanups in separate commits, including one I overlooked in rust-lang/rust#151228.
Currently all core and std macros are automatically added to the prelude
via #[macro_use]. However a situation arose where we want to add a new macro
`assert_matches` but don't want to pull it into the standard prelude for
compatibility reasons. By explicitly exporting the macros found in the core and
std crates we get to decide on a per macro basis and can later add them via
the rust_20xx preludes.
Use `rand` crate more idiomatically
Small cleanup, found while working on something else.
We were using `rand` un-idiomatically in a couple of places, and it was bugging me...
`Vec::push` in consts MVP
Example:
```rust
const X: &'static [u32] = {
let mut v = Vec::with_capacity(6);
let mut x = 1;
while x < 42 {
v.push(x);
x *= 2;
}
assert!(v.len() == 6);
v.const_make_global()
};
assert_eq!([1, 2, 4, 8, 16, 32], X);
```
Oh this is fun...
* We split out the implementation of `Global` such that it calls `intrinsics::const_allocate` and `intrinsics::const_deallocate` during compile time. This is achieved using `const_eval_select`
* This allows us to `impl const Allocator for Global`
* We then constify everything necessary for `Vec::with_capacity` and `Vec::push`.
* Added `Vec::const_make_global` to leak and intern the final value via `intrinsics::const_make_global`. If we see any pointer in the final value of a `const` that did not call `const_make_global`, we error as implemented in rust-lang/rust#143595.
r? `@rust-lang/wg-const-eval`
To-do for me:
* [x] Assess the rustdoc impact of additional bounds in the method
* [x] ~~Increase test coverage~~ I think this is enough for an unstable feature.
Cleanup linked list
- Replaces some checked_sub().unwrap_or(0) with saturating_sub().
- Replaces NonNull::from(Box::leak(node)) with Box::into_non_null(node)
Jonathan Brouwer