It uses very old language that is more confusing today than helpful,
including references to `SubstNt` that no longer exists. The comment
above `TokenStream` is better, and suffices for a basic understanding of
these types.
This commit combines `MatchedTokenTree` and `MatchedNonterminal`, which
are often considered together, into a single `MatchedSingle`. It shares
a representation with the newly-parameterized `ParseNtResult`.
This will also make things much simpler if/when variants from
`Interpolated` start being moved to `ParseNtResult`.
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
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.
