Sync rustc_codegen_cranelift
This time Cranelift has been updated to 0.98. A couple of bugs have been fixed and a decent amount of x86 vendor intrinsics have been implemented.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
limit `change_visibility` assist to applicable items
this pr limits the `change_visibility` assist to applicable items. top level items in this context means items that are not nested within `fn`s or `trait`s.
now
```rs
fn foo {
// assists on this `struct` keyword won't include `change_visibility`
struct Bar {}
}
trait Foo {
// same with the `fn` here
fn bar();
}
```
new lint: `redundant_locals`
This lint checks for code like the following:
```rs
let x = 1;
let x = x;
```
It checks (afaik) all cases where a binding is shadowed by its own value in the same block, including function parameters. This has no effect and is almost certainly accidental, so it's in the `correctness` category like `self_assignment`.
This also lays the groundwork for a more generalized version of #5102.
changelog: new lint: [`redundant_local`]
Multibyte character removal in String::pop and String::remove doctests
I think it would be useful to have the doctests for the `String::pop()` and `String::remove()` methods demonstrate that they work on multibyte UTF-8 sequences.
Fix size_hint for EncodeUtf16
More realistic upper and lower bounds, and handle the case where the iterator is located within a surrogate pair.
Resolves#113897
fix docs & example for `std::os::unix::prelude::FileExt::write_at`
Changelog:
* used `File::create` instead of `File::read` to get a writeable file
* explicity mentioned the bug with `pwrite64` in docs
Unfortunately, I don't think that there is really much we can do about this since the feature has already been stabilised.
We could potentially add a clippy lint warning people on Linux that using `write_at` with the `O_APPEND` flag does not exhibit the behaviour that they would have assumed.
fixes#113627
Allow limited access to `OsString` bytes
This extends #109698 to allow no-cost conversion between `Vec<u8>` and `OsString` as suggested in feedback from `os_str_bytes` crate in #111544.
Update the tracking issue for `const_cstr_from_ptr`
Tracking issue #101719 was for `const_cstr_methods`, #113219 is a new issue specific for `const_cstr_from_ptr`.
(I believe #101719 could also be closed)
```@rustbot``` label +T-libs-api +A-docs
Normalize expected ty in call arguments
fix#15321
I'm not sure if we should do this, or add a normalize in the beginning of `infer_expr_inner`, or somewhere else. r? `@lowr`
fix dogfood lints in `redundant_local`
keep `redundant_local` from running in proc macros
rewrite `redundant_local` as late pass
make redundant_local's `find_binding` more readable
pluralize `redundant_locals` name
add test for `redundant_locals` in macros
test `redundant_locals` in proc macros
use more destructuring in `redundant_locals`
fix: format redundant_locals.rs
ignore needless_pass_by_mut_ref in redundant_locals test
New lint [`absolute_paths`]
Closes#10568
Maybe we should make the max segments allowed a configuration option? I see quite a bit of 3-segment paths in clippy, and while I think only really `<mod/type>::<item>` or `<item>` should be (usually) used but anything above may be too widespread 😕
PS, despite this being "max segments allowed" it only lints if it's absolute, as is the point of the lint, e.g., `std::io::ErrorKind::etc` is linted but `io::ErrorKind::NotFound::etc` isn't
changelog: New lint [`absolute_paths`]
