clarify that realloc refreshes pointer provenance even when the allocation remains in-place
This [matches what C does](https://en.cppreference.com/w/c/memory/realloc):
> The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was in-place).
Cc `@rust-lang/wg-allocators`
Check fat pointer metadata compatibility modulo regions
Regions don't really mean anything anyways during hir typeck.
If this `erase_regions` makes anyone nervous, it's probably equally valid to just equate the types using a type relation, but regardless we should _not_ be using strict type equality while region variables are present.
Fixes#103384
make miri-seed a regular integer, and also set layout-seed in many-seeds
This makes the seed format consistent between `-Zlayout-seed` and `-Zmiri-seed`.
Rollup of 6 pull requests
Successful merges:
- #103901 (Add tracking issue for `const_arguments_as_str`)
- #104112 (rustdoc: Add copy to the description of repeat)
- #104435 (`VecDeque::resize` should re-use the buffer in the passed-in element)
- #104467 (Fix substraction with overflow in `wrong_number_of_generic_args.rs`)
- #104608 (Cleanup macro matching recovery)
- #104626 (Fix doctest errors related to rustc_middle)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Cleanup macro matching recovery
The retry has been implemented already in #104335. Also removes a `HACK` comment that's not really needed anymore because the "don't recover during macro matching" isn't really a hack but correct behavior.
Fix substraction with overflow in `wrong_number_of_generic_args.rs`
Fixes#104287
This issue happens in the `suggest_moving_args_from_assoc_fn_to_trait_for_qualified_path` function, which seems to run before the error checking facilities can catch an invalid use of generic arguments. Thus we get a subtraction with overflow because the code implicitly assumes that the source program makes sense (or is this assumption not true even if the program is correct?).
`VecDeque::resize` should re-use the buffer in the passed-in element
Today it always copies it for *every* appended element, but one of those clones is avoidable.
This adds `iter::repeat_n` (https://github.com/rust-lang/rust/issues/104434) as the primitive needed to do this. If this PR is acceptable, I'll also use this in `Vec` rather than its custom `ExtendElement` type & infrastructure that is harder to share between multiple different containers:
101e1822c3/library/alloc/src/vec/mod.rs (L2479-L2492)
try_normalize_after_erasing_regions: promote an assertion to always run
In https://github.com/rust-lang/miri/issues/2433 this assertion has been seen to trigger, so it might be worth actually checking this? Regressing debug assertions are very easy to miss until much later, and then they become quite hard to debug.
Don't duplicate last cdb debuginfo test command
cdb scripts interpret a blank line to mean "repeat the last command", similar to what happens when running the debugger from a console. The code for compiletest that constructs the debugger script was inserting a blank line between the last command and the "quit" command. This caused the last command to be executed twice. This can cause some confusion since the `-check` lines are expecting the output in a certain order. But printing the last command twice causes that order-assumption to fail, and that can cause confusion.
This fixes it by removing the blank line.
AFAICT, gdb and lldb scripts don't have the same behavior with blank lines (and the gdb code doesn't add any blank lines anyways).
Rarranging the substration and equality check into an addition and an equality
check is sufficient.
Algebra is cool, isn't it?
Co-authored-by: Michael Goulet <michael@errs.io>
* Fix doc examples for Platforms with underaligned integer primitives.
* Mutable pointer doc examples use mutable pointers.
* Fill out tracking issue.
* Minor formatting changes.
