more clippy fixes
* use is_empty() instead of len comparison (clippy::len_zero)
* use if let instead of while let loop that never loops (clippy::never_loop)
* remove redundant returns (clippy::needless_return)
* remove redundant closures (clippy::redundant_closure)
* use if let instead of match and wildcard pattern (clippy::single_match)
* don't repeat field names redundantly (clippy::redundant_field_names)
r? @Centril
Fix incorrect documentation for `str::{split_at, split_at_mut}`
The documentation for each method currently states:
> Panics if `mid` is not on a UTF-8 code point boundary, or if it is beyond the last code point of the string slice.
However, this is not consistent with the real behavior, or that of the corresponding methods for `[T]` slices. A comment inside each of the `str` methods states:
> is_char_boundary checks that the index is in [0, .len()]
That is what I would expect the behavior to be, and in fact this seems to be the real behavior. For example ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8e03dcc209d4dd176df2297523f9fee1)):
```rust
fn main() {
// Prints ("abc", "") and doesn't panic
println!("{:?}", "abc".split_at(3));
}
```
In this case, I would interpret "the last code point of the string slice" to mean the byte at index 2 in UTF-8. However, it is possible to pass an index of 3, which is definitely "beyond the last code point of the string slice".
I think that this is much clearer, but feel free to bikeshed.
std: Fix over-aligned allocations on wasm32-wasi
The wasm32-wasi target delegates its malloc implementation to the
functions in wasi-libc, but the invocation of `aligned_alloc` was
incorrect by passing the number of bytes requested first rather than the
alignment. This commit swaps the order of these two arguments to ensure
that we allocate over-aligned memory correctly.
infer array len from pattern
closes#70529
This still errors in the following case
```rust
#![feature(const_generics)]
fn arr<const N: usize>() -> [u8; N] {
todo!()
}
fn main() {
match arr() {
[5, ..] => (),
//~^ ERROR cannot pattern-match on an array without a fixed length
[_, _] => (),
}
}
```
Considering that this should be rare and is harder to implement I would merge this PR without *fixing* the above.
Add long error code for error E0226
Added a long description message for error E0226, which previously did not exist.
As requested in issue #61137
r? @GuillaumeGomez
Optimize strip_prefix and strip_suffix with str patterns
As mentioned in https://github.com/rust-lang/rust/issues/67302#issuecomment-585639226.
I'm not sure whether adding these methods to `Pattern` is desirable—but they have default implementations so the change is backwards compatible. Plus it seems like they're slated for wholesale replacement soon anyway? #56345
----
Constructing a Searcher in strip_prefix and strip_suffix is
unnecessarily slow when the pattern is a fixed-length string. Add
strip_prefix and strip_suffix methods to the Pattern trait, and add
optimized implementations of these methods in the str implementation.
The old implementation is retained as the default for these methods.
use is_empty() instead of len comparison (clippy::len_zero)
use if let instead of while let loop that never loops (clippy::never_loop)
remove redundant returns (clippy::needless_return)
remove redundant closures (clippy::redundant_closure)
use if let instead of match and wildcard pattern (clippy::single_match)
don't repeat field names redundantly (clippy::redundant_field_names)
The wasm32-wasi target delegates its malloc implementation to the
functions in wasi-libc, but the invocation of `aligned_alloc` was
incorrect by passing the number of bytes requested first rather than the
alignment. This commit swaps the order of these two arguments to ensure
that we allocate over-aligned memory correctly.
Constructing a Searcher in strip_prefix and strip_suffix is
unnecessarily slow when the pattern is a fixed-length string. Add
strip_prefix and strip_suffix methods to the Pattern trait, and add
optimized implementations of these methods in the str implementation.
The old implementation is retained as the default for these methods.
Polonius: update to 0.12.1, fix more move errors false positives, update test expectations
This PR:
- updates `polonius-engine` to version 0.12.1 to fix some move errors false positives
- fixes a fact generation mistake creating the other move errors false positives
- updates the test expectations for the polonius compare-mode so that all (minus the 2 OOMs) ui tests pass again (matching the [analysis doc](https://hackmd.io/CjYB0fs4Q9CweyeTdKWyEg?view) starting at case 34)
In my opinion, this is safe to rollup.
r? @nikomatsakis
avoid creating unnecessary reference in Windows Env iterator
Discovered in https://github.com/rust-lang/miri/pull/1225: the Windows `Env` iterator violates Stacked Borrows by creating an `&u16`, turning it into a raw pointer, and then accessing memory outside the range of that type.
There is no need to create a reference here in the first place, so the fix is trivial.
Cc @JOE1994
Cc https://github.com/rust-lang/unsafe-code-guidelines/issues/134
Make `Visitor::visit_body` take a plain `&Body`
`ReadOnlyBodyAndCache` has replaced `&Body` in many parts of the code base that don't care about basic block predecessors. This includes the MIR `Visitor` trait, which I suspect resulted in many unnecessary changes in #64736. This reverts part of that PR to reduce the number of places where we need to pass a `ReadOnlyBodyAndCache`.
In the long term, we should either give `ReadOnlyBodyAndCache` more ergonomic name and replace all uses of `&mir::Body` with it at the cost of carrying an extra pointer everywhere, or use it only in places that actually need access to the predecessor cache. Perhaps there is an even nicer alternative.
r? @Nashenas88
