...which seems not to be available on some platforms.
Or maybe it is under a different name but I don't want to deal with that
Instead, use two u64s. This isn't exactly the same, but we already have
some coverage of the packed u128 case in another test, so it's not
essential to have it here.
Coverage has two FFI functions for computing the hash of a byte string. One
takes a ptr/len pair, and the other takes a NUL-terminated C string.
But on closer inspection, the C string version is unnecessary. The calling-side
code converts a Rust `&str` into a C string, and the C++ code then immediately
turns it back into a ptr/len string before actually hashing it.
The function body immediately treats it as a slice anyway, so this just makes
it possible to call the hash function with arbitrary read-only byte slices.
Ignore flaky clippy tests.
These tests are frequently failing due to an issue in ui_test. ui_test doesn't appear to have a blanket ignore instruction that I could find, so I just approximated it with ignoring both 32 and 64 bit.
Fixes#113585
(re-)tighten sourceinfo span of adjustments in MIR
Diagnostics rely on the spans of MIR statements being (approximately) correct in order to give suggestions relative to that span (i.e. `shrink_to_hi` and `shrink_to_lo`).
I discovered that we're *intentionally* lowering THIR exprs with their parent expr's span if they come from adjustments that are due to a parent expression. While I understand why that may be desirable to demonstrate the relationship of an adjustment and the expression that requires it, it leads to
1. very verbose borrowck output
2. incorrect spans for suggestions
Some diagnostics get around that by giving suggestions relative to other spans we've collected during MIR lowering, such as the span of the method's identifier (e.g. `name` in `.name()`), but this doesn't work too well when things come from desugaring.
I assume it also has lead to numerous tweaks and complications to diagnostics code down the road, which this PR doesn't necessarily aim to fix but may open the gates to fixing later... The last three commits are simplifications due to the fact that we can assume that the move span actually points to what is being moved (and a test).
This regressed in #89110, which was debated somewhat in #90286. cc `@Aaron1011` who originally made this change.
r? diagnostics
Fixes#113547Fixes#111016
miri: protect Move() function arguments during the call
This gives `Move` operands a meaning specific to function calls:
- for the duration of the call, the place the operand comes from is protected, making all read and write accesses insta-UB.
- the contents of that place are reset to `Uninit`, so looking at them again after the function returns, we cannot observe their contents
Turns out we can replace the existing "retag return place" hack with the exact same sort of protection on the return place, which is nicely symmetric.
Fixes https://github.com/rust-lang/rust/issues/112564
Fixes https://github.com/rust-lang/miri/issues/2927
This starts with a Miri rustc-push, since we'd otherwise conflict with a PR that recently landed in Miri.
(The "miri tree borrows" commit is an unrelated cleanup I noticed while doing the PR. I can remove it if you prefer.)
r? `@oli-obk`
style-guide: Fix chain example to match rustfmt behavior
The style guide gave an example of breaking a multi-line chain element
and all subsequent elements to a new line, but that same example and the
accompanying text also had several chain items stacked on the first
line. rustfmt doesn't do this, except when the rule saying to combine
```
shrt
.y()
```
into
```
shrt.y()
```
applies.
This is a bugfix to match rustfmt behavior, so it's not a breaking change, and
it just needs a ``@rust-lang/style`` reviewer to r+.
Previously, forgetting to call `interface::set_thread_safe_mode` would cause the following ICE:
```
thread 'rustc' panicked at 'uninitialized dyn_thread_safe mode!', /rustc/dfe0683138de0959b6ab6a039b54d9347f6a6355/compiler/rustc_data_structures/src/sync.rs:74:18
```
This calls `set_thread_safe_mode` in `interface::run_compiler` to avoid requiring it in the caller.
Fixes `tests/run-make-fulldeps/issue-19371` when parallel-compiler is enabled.
This was not the correct fix. The problem was two-fold:
- `download-rustc` didn't respect `llvm.assertions`
- `rust-dev` was missing a bump to `download-ci-llvm-stamp`
The first is fixed in this PR and the latter was fixed a while ago. Revert this change to avoid breaking `rpath = false`.
