nice_region_error: Include lifetime placeholders in error output
As you can see in src/test/ui/traits/self-without-lifetime-constraint.stderr
you can get very confusing type names if you don't have this.
Fixes#87763
Stabilise unix_process_wait_more, extra ExitStatusExt methods
This stabilises the feature `unix_process_wait_more`. Tracking issue #80695, FCP needed.
This was implemented in #79982 and merged in January.
Implement split_array and split_array_mut
This implements `[T]::split_array::<const N>() -> (&[T; N], &[T])` and `[T; N]::split_array::<const M>() -> (&[T; M], &[T])` and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing, similar to #74373, #75026, etc. Fixes#74674.
This implements `[T; N]::split_array` returning an array and a slice. Ultimately, this is probably not what we want, we would want the second return value to be an array of length N-M, which will likely be possible with future const generics enhancements. We need to implement the array method now though, to immediately shadow the slice method. This way, when the slice methods get stabilized, calling them on an array will not be automatic through coercion, so we won't have trouble stabilizing the array methods later (cf. into_iter debacle).
An unchecked version of `[T]::split_array` could also be added as in #76014. This would not be needed for `[T; N]::split_array` as that can be compile-time checked. Edit: actually, since split_at_unchecked is internal-only it could be changed to be split_array-only.
Inline CStr::from_ptr
Inlining this function is valuable, as it allows LLVM to apply `strlen`-specific optimizations without having to enable LTO.
For instance, the following function:
```rust
pub fn f(p: *const c_char) -> Option<u8> {
unsafe { CStr::from_ptr(p) }.to_bytes().get(0).copied()
}
```
Looks like this if `CStr::from_ptr` is allowed to be inlined.
```asm
before:
push rax
call qword ptr [rip + std::ffi::c_str::CStr::from_ptr@GOTPCREL]
mov rcx, rax
cmp rdx, 1
sete dl
test rax, rax
sete al
or al, dl
jne .LBB1_2
mov dl, byte ptr [rcx]
.LBB1_2:
xor al, 1
pop rcx
ret
after:
mov dl, byte ptr [rdi]
test dl, dl
setne al
ret
```
Note that optimization turned this from O(N) to O(1) in terms of performance, as LLVM knows that it doesn't really need to call `strlen` to determine whether a string is empty or not.
Rollup of 14 pull requests
Successful merges:
- #87537 (Clarify undefined behaviour in binary heap, btree and hashset docs)
- #88624 (Stabilize feature `saturating_div` for rust 1.58.0)
- #89257 (Give better error for `macro_rules name`)
- #89665 (Ensure that pushing empty path works as before on verbatim paths)
- #89895 (Don't mark for loop iter expression as desugared)
- #89922 (Update E0637 description to mention `&` w/o an explicit lifetime name)
- #89944 (Change `Duration::[try_]from_secs_{f32, f64}` underflow error)
- #89991 (rustc_ast: Turn `MutVisitor::token_visiting_enabled` into a constant)
- #90028 (Reject closures in patterns)
- #90069 (Fix const qualification when executed after promotion)
- #90078 (Add a regression test for issue-83479)
- #90114 (Add some tests for const_generics_defaults)
- #90115 (Add test for issue #78561)
- #90129 (triagebot: Treat `I-*nominated` like `I-nominated`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
triagebot: Treat `I-*nominated` like `I-nominated`
rustbot doesn't allow unauthenticated users to set `I-nominated`; apply the same permissions to the new `I-*nominated` labels.
Add some tests for const_generics_defaults
I think this covers some of the stuff required for stabilisation report, some of these tests are probably covering stuff we already have but it can't hurt to have more :)
r? ````@lcnr````
Fix const qualification when executed after promotion
The const qualification was so far performed before the promotion and
the implementation assumed that it will never encounter a promoted.
With `const_precise_live_drops` feature, checking for live drops is
delayed until after drop elaboration, which in turn runs after
promotion. so the assumption is no longer true. When evaluating
`NeedsNonConstDrop` it is now possible to encounter promoteds.
Use type base qualification for the promoted. It is a sound
approximation in general, and in the specific case of promoteds and
`NeedsNonConstDrop` it is precise.
Fixes#89938.
rustc_ast: Turn `MutVisitor::token_visiting_enabled` into a constant
It's a visitor property rather than something that needs to be determined at runtime
Update E0637 description to mention `&` w/o an explicit lifetime name
Deal with https://github.com/rust-lang/rust/issues/89824#issuecomment-941598647. Another solution would be splitting the error code into two as (I think) it's a bit unclear to users why they have the same error code.
Don't mark for loop iter expression as desugared
We typically don't mark spans of lowered things as desugared. This helps Clippy rightly discern when code is (not) from expansion. This was discovered by ``@flip1995`` at https://github.com/rust-lang/rust-clippy/pull/7789#issuecomment-939289501.
Stabilize feature `saturating_div` for rust 1.58.0
The tracking issue is #89381
This seems like a reasonable simple change(?). The feature `saturating_div` was added as part of the ongoing effort to implement a `Saturating` integer type (see #87921). The implementation has been discussed [here](https://github.com/rust-lang/rust/pull/87921#issuecomment-899357720) and [here](https://github.com/rust-lang/rust/pull/87921#discussion_r691888556). It extends the list of saturating operations on integer types (like `saturating_add`, `saturating_sub`, `saturating_mul`, ...) by the function `fn saturating_div(self, rhs: Self) -> Self`.
The stabilization of the feature `saturating_int_impl` (for the `Saturating` type) needs to have this stabilized first.
Closes#89381
Clarify undefined behaviour in binary heap, btree and hashset docs
Previously, it wasn't clear whether "This could include" was referring to logic errors, or undefined behaviour. Tweak wording to clarify this sentence does not relate to UB.
Previously, it wasn't clear whether "This could include" was referring
to logic errors, or undefined behaviour. Tweak wording to clarify this
sentence does not relate to UB.
Fix typo for invalid_null_ptr_usage and missing_inline_in_public_items.
Fix typo for invalid_null_ptr_usage and missing_inline_in_public_items.
changelog: none
Rollup of 14 pull requests
Successful merges:
- #86984 (Reject octal zeros in IPv4 addresses)
- #87440 (Remove unnecessary condition in Barrier::wait())
- #88644 (`AbstractConst` private fields)
- #89292 (Stabilize CString::from_vec_with_nul[_unchecked])
- #90010 (Avoid overflow in `VecDeque::with_capacity_in()`.)
- #90029 (Add test for debug logging during incremental compilation)
- #90031 (config: add the option to enable LLVM tests)
- #90048 (Add test for line-number setting)
- #90071 (Remove hir::map::blocks and use FnKind instead)
- #90074 (2229 migrations small cleanup)
- #90077 (Make `From` impls of NonZero integer const.)
- #90097 (Add test for duplicated sidebar entries for reexported macro)
- #90098 (Add test to ensure that the missing_doc_code_examples is not triggered on foreign trait implementations)
- #90099 (Fix MIRI UB in `Vec::swap_remove`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix MIRI UB in `Vec::swap_remove`
Fixes#90055
I find it weird that `Vec::swap_remove` read the last element to the stack just to immediately put it back in the `Vec` in place of the one at index `index`. It seems much more natural to me to just read the element at position `index` and then move the last element in its place. I guess this might also slightly improve codegen.
Make `From` impls of NonZero integer const.
I also changed the feature gate added to `From` impls of Atomic integer to `const_num_from_num` from `const_convert`.
Tracking issue: #87852
Remove hir::map::blocks and use FnKind instead
The principal tool is `FnLikeNode`, which is not often used and can be easily implemented using `rustc_hir::intravisit::FnKind`.
Add test for line-number setting
The first commit updates the version of the package to be able to have multi-line commands (which looks much nicer for this test).
r? ````@jsha````
config: add the option to enable LLVM tests
I'm working on some LLVM patches in concert with a Rust patch, and it's
helping me quite a bit to have this as an option. It doesn't seem that
hard, so I figured I'd formalize it in x.py and send it upstream.
Add test for debug logging during incremental compilation
Debug logging during incremental compilation had been broken for some
time, until #89343 fixed it (among other things). Add a test so this is
less likely to break without being noticed. This test is nearly a copy
of the `src/test/ui/rustc-rust-log.rs` test, but tests debug logging in
the incremental compliation code paths.
Avoid overflow in `VecDeque::with_capacity_in()`.
The overflow only happens if alloc is compiled with overflow checks enabled and the passed capacity is greater or equal 2^(usize::BITS-1). The overflow shadows the expected "capacity overflow" panic leading to a test failure if overflow checks are enabled for std in the CI.
Unblocks [CI: Enable overflow checks for test (non-dist) builds #89776](https://github.com/rust-lang/rust/pull/89776).
For some reason the overflow is only observable with optimization turned off, but that is a separate issue.
