Fix ICE when trying to GC a Stack with an unknown bottom
Fixes https://github.com/rust-lang/rust/issues/103167
`@RalfJung` I prefer this approach because the whole GC system is sloppy already in order to be efficient (doesn't run often, ignores small stacks) so a bit more imprecision for a simple implementation seems worth it to me. But I'm of course willing to be convinced otherwise.
Update Applicability of `redundant_allocation` lint from `MachineApplicable` to `MaybeIncorrect`
This changes `redundant_allocation` lint from MachineApplicable to MaybeIncorrect
```
changelog: [`redundant_allocation]: Change Applicability from MachineApplicable to MaybeIncorrect
```
fixes#6243
---
changelog: [`redundant_allocation`]: Change Applicability from MachineApplicable to MaybeIncorrect
Use Set instead of Vec in transitive_relation
Helps with #103195. It doesn't fix the underlying quadraticness but it makes it _a lot_ faster to an extent where even doubling the amount of nested references still takes less than two seconds (50s on nightly).
I want to see whether this causes regressions (because the vec was usually quite small) or improvements (as lookup for bigger sets is now much faster) in real code.
use Scalar return types for Windows shims
I started doing this while working on https://github.com/rust-lang/miri/issues/2595; now I don't need the rest of this patch but this part still makes sense.
All tools meant to be shipped with host toolchains only should be marked
as `ONLY_HOSTS = true`, but rust-analyzer was marked as `ONLY_HOSTS =
false` incorrectly. This meant that bootstrap attempted to build
rust-analyzer for cross-compilation-only targets, causing errors because
libstd is not present on some of them.
It will still be possible to cross-compile rust-analyzer by passing a
different --host flag to ./x, like you can cross-compile other tools.
Make transpose const and inline
r? `@scottmcm`
- These should have been const from the beginning since we're never going to do more than a transmute.
- Inline these always because that's what every other method in MaybeUninit which simply casts does. :) Ok, but a stronger justification is that because we're taking in arrays by `self`, not inlining would defeat the whole purpose of using `MaybeUninit` due to the copying.
Let expressions on RHS shouldn't be terminating scopes
Fixes#100276.
Before this PR, we were unconditionally marking the RHS of short-circuiting binary expressions as a terminating scope.
In the case of a let chain where the `let` expression was on the RHS, this meant that temporaries within the `let` expr would only live until the end of the expression. Since this only affected the RHS, this led to surprising behavior ([example](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=d1b0a5d1f01882f9c89c2194a75eb19f)).
After this PR, we only mark the RHS as a terminating scope if it is not a `let` expression.
Standardize "use parentheses to call" suggestions between typeck and trait selection
1. Suggest calling constructors, since they're basically `FnDef`s but they have a different def kind and hir representation, so we were leaving them out.
2. Standardize the call suggestions between trait fulfillment errors and type mismatch. In the type mismatch suggestion, we suggest `/* Ty */` as the placeholder for an arg, and not the parameter's name, which is less helpful.
3. Use `predicate_must_hold_modulo_regions` instead of matching on `EvaluationResult` -- this might cause some suggestions to be filtered out, but we really shouldn't be suggesting a call if it "may" hold, only when it "must" hold.
4. Borrow some logic from `extract_callable_info` to generalize this suggestion to fn pointers, type parameters, and opaque types.
Fixes#102852
Handle core dumps output in QEMU user mode
In addition to the whole-system emulation/virtualization, QEMU also supports user-mode emulation, where the emulation happens as a normal process inside the parent system. This allows running most tests by simply spawning remote-test-server inside user-mode emulation.
Unfortunately, QEMU always writes its own message in addition to the system one when a core dump happens, which breaks a few tests which match on the exact output of the system.
This PR changes those tests to strip the (possible) QEMU output before checking if the output is expected.
Ideas on getting information about borrow stacks during execution
From time to time people ask what some borrow stack looks like in some code. I just know that I am terrible at doing Stacked Borrows by hand, so I always toss together something like this.
I know that Miri has logging, but I've never found it particularly useful because there's just too much output. Also I personally don't think about exactly what the state of a borrow stack is, but this seems to be something that newcomers to Stacked Borrows always want.
Update: This has been sitting as S-waiting-on-author for a long time. I bring it out from time to time to explain Stacked Borrows to people, and just now `@JakobDegen` said
> Can we please merge that btw? It's such a valuable teaching tool
> Interfaces can be fixed later
I'm inclined to trust Jake's judgement here.
- Make the structure of the two variants more similar.
- Add some comments.
- Move various conditional `use` items inside the function that uses
them.
- Inline some closures.
Partially fix `src/test/run-make/coverage-reports` when cross-compiling
The test does not work on cross-compiled targets because the --target flag was not passed to rustc inside the test. This commit fixes that by adding the flag to the invocations.
Note that the test still fails on cross-compiled targets using remote-test, as remote-test is not capable (yet) of sending back to the host system the `*.profraw` file generated by the instrumentation.
Because of that, this is only a partial fix, and the test has been ignored on cross-compilation.
Optimize `slice_iter.copied().next_chunk()`
```
OLD:
test iter::bench_copied_array_chunks ... bench: 371 ns/iter (+/- 7)
NEW:
test iter::bench_copied_array_chunks ... bench: 31 ns/iter (+/- 0)
```
The default `next_chunk` implementation suffers from having to assemble the array byte by byte via `next()`, checking the `Option<&T>` and then dereferencing `&T`. The specialization copies the chunk directly from the slice.
Rollup of 6 pull requests
Successful merges:
- #101889 (doc: rewrite doc for uint::{carrying_add,borrowing_sub})
- #102507 (More slice::partition_point examples)
- #103164 (rustdoc: remove CSS ``@media` (min-width: 701px)`)
- #103189 (Clean up code-color and headers-color rustdoc GUI tests)
- #103203 (Retrieve LLVM version from llvm-filecheck binary if it is not set yet)
- #103204 (Add some more autolabels)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
