Disable `cast_lossless` when casting to u128 from any (u)int type
Fixes https://github.com/rust-lang/rust-clippy/issues/12492
Disables `cast_lossless` when casting to u128 from any int or uint type. The lint states that when casting to any int type, there can potentially be lossy behaviour if the source type ever exceeds the size of the destination type in the future, which is impossible with a destination of u128.
It's possible this is a bit of a niche edge case which is better addressed by just disabling the lint in code, but I personally couldn't think of any good reason to still lint in this specific case - maybe except if the source is a bool, for readability reasons :).
changelog: FP: `cast_lossless`: disable lint when casting to u128 from any (u)int type
This target is a Tier 3 target so it's not tested on CI, and it's broken
since last used so this commit fixes a small unwind-related issue that
cropped up in the meantime.
This is implemented with the freshly-released Wasmtime 19 and should
prevent beta breakage from wasm tests that was observed and fixed
in #122640 again.
fix OOB pointer formed in Vec::index
Move the length check to before using `index` with `ptr::add` to prevent an out of bounds pointer from being formed.
Fixes#122760
Make `assigning_clones` MSRV check more precise
Continuation of #12511
`clone_into` is the only suggestion subject to the 1.63 MSRV requirement, and the lint should still emit other suggestions regardless of the MSRV.
changelog: [assigning_clones]: only apply MSRV check to `clone_into` suggestions.
When comparing SVG tests against their blessed version, ignore the first line
`anstyle_svg` has some weird non-determinism in the width parameter, which makes tests blessed in one environment to fail in another. This is the *only* non-determinism detected so far, so we modify the diff check to ignore the first line of the SVG. In order for a test to fail/be updated by `--bless`, a different part of the file needs to also have changed. If other sources of non-determinism are found, we should back out of the "`--color=always` means `.svg`" change.
r? `@compiler-errors`
`anstyle_svg` has some weird non-determinism in the width parameter, which makes tests blessed in one environment to fail in another. This is the *only* non-determinism detected so far, so we modify the diff check to ignore the first line of the SVG. In order for a test to fail/be updated by `--bless`, a different part of the file needs to also have changed.
Print the crates not available as static
This prints out the crates not available to be statically linked when static linking is preferred and we run into an error with duplicated crates.
Filed #122758 to track a proper fix, but this seems to solve the
problem in the meantime and is probably OK in terms of impact on
(internal) doc quality.
For async closures, cap closure kind, get rid of `by_mut_body`
Right now we have three `AsyncFn*` traits, and three corresponding futures that are returned by the `call_*` functions for them. This is fine, but it is a bit excessive, since the future returned by `AsyncFn` and `AsyncFnMut` are identical. Really, the only distinction we need to make with these bodies is "by ref" and "by move".
This PR removes `AsyncFn::CallFuture` and renames `AsyncFnMut::CallMutFuture` to `AsyncFnMut::CallRefFuture`. This simplifies MIR building for async closures, since we don't need to build an extra "by mut" body, but just a "by move" body which is materially different.
We need to do a bit of delicate handling of the ClosureKind for async closures, since we need to "cap" it to `AsyncFnMut` in some cases when we only care about what body we're looking for.
This also fixes a bug where `<{async closure} as Fn>::call` was returning a body that takes the async-closure receiver *by move*.
This also helps align the `AsyncFn` traits to the `LendingFn` traits' eventual designs.
