Instead of repeatedly merging the two smallest CGUs, we now use a
merging algorithm that aims to minimize the duplication of inlined
functions.
`exa-0.10.1` was one benchmark that saw particularly good results. The
old CGU stats:
```
INTERNALIZE
- unique items: 2774 (1216 root + 1558 inlined), unique size: 122065 (77219 root + 44846 inlined)
- placed items: 3834 (1216 root + 2618 inlined), placed size: 154552 (77219 root + 77333 inlined)
- placed/unique items ratio: 1.38, placed/unique size ratio: 1.27
- CGUs: 16, mean size: 9659.5, sizes: [11791, 11634, 11173, 10987, 10939, 10507, 9992, 9813, 9593, 9580, 9030, 8447, 7975, 7961, 7876, 7254]
```
The new CGU stats:
```
INTERNALIZE
- unique items: 2774 (1216 root + 1558 inlined), unique size: 122065 (77219 root + 44846 inlined)
- placed items: 3626 (1216 root + 2410 inlined), placed size: 147201 (77219 root + 69982 inlined)
- placed/unique items ratio: 1.31, placed/unique size ratio: 1.21
- CGUs: 16, mean size: 9200.1, sizes: [11634, 10939, 10227, 9555, 9178, 9167, 8879, 8804, 8604, 8603 (x3), 8602 (x2), 8601, 8600]
```
The difference is in the number of inlined items. There are 1558 unique
inlined items. With the old algorithm these were placed 2618 times,
resulting in 1060 duplicates. With the new algorithm these were placed
2410 times, resulting in 852 duplicates. Also, the mean CGU size dropped
from 9659.5 to 9200.1, and the CGU size distribution tightened, with the
biggest one a little smaller and the smallest ones a little bigger.
Restrict recursive opaque type check
We have a recursive opaque check in writeback to avoid inferring the hidden of an opaque type to be itself:
33a2c2487a/compiler/rustc_hir_typeck/src/writeback.rs (L556-L575)
Issue #113619 treats `make_option2` as not defining the TAIT `TestImpl` since it is inferred to have the definition `TestImpl := B<TestImpl>`, which fails this check. This regressed in #102700 (5d15beb591), I think due to the refactoring that made us record the hidden types of TAITs during writeback.
However, nothing actually seems to go bad if we relax this recursion checker to only check for directly recursive definitions. This PR fixes#113619 by changing this recursive check from being a visitor to just checking that the hidden type is exactly the same as the opaque being inferred.
Alternatively, we may be able to fix#113619 by restricting this recursion check only to RPITs/async fns. It seems to only be possible to use misuse the recursion check to cause ICEs for TAITs (though I didn't try too hard to create a bad RPIT example... may be possible, actually.)
r? `@oli-obk`
--
Fixes#113314
Fix removal span calculation of `unused_qualifications` suggestion
Given a path such as `std::ops::Index<str>`, calculate the unnecessary qualification removal span by computing the beginning of the entire span until the ident span of the last path segment, which handles generic arguments and lifetime arguments in the last path segment. Previous logic only kept the ident span of the last path segment which is incorrect.
Closes#113808.
add mips64r6 and mips32r6 as target_arch values
This PR introduces `"mips32r6"` and `"mips64r6"` as valid `target_arch` values, and would be the arch value used by Tier-3 targets `mipsisa32r6-unknown-linux-gnu`, `mipsisa32r6el-unknown-linux-gnu`, `mipsisa64r6-unknown-linux-gnuabi64` and `mipsisa64r6el-unknown-linux-gnuabi64`.
This PR was inspired by `rustix` attempting to link traditional mips64el objects with mips64r6el objects when building for mips64r6, even though `rustix` recently removed outline assembly support. This is because currently this target's `target_arch` is `"mips64"` and rustix has its respective assembly implementation as well as a pre-compiled little-endian static library prepared for mips64el, a tier-2 target with the same `target_arch`. After some [discussions on zulip](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Add.20New.20Values.20To.20MIPS_ALLOWED_FEATURES.20compiler-team.23595), I decided to treat mips64r6 as an independent architecture from Rust's POV, since these two architectures are incompatible anyway.
This PR is now waiting for `libc` to release a new version with [support](https://github.com/rust-lang/libc/pull/3268) for these `target_arch` values. It is not expected to introduce changes to any other target, especially Tier-1 and Tier-2 targets.
This PR has its corresponding [MCP](https://github.com/rust-lang/compiler-team/issues/632) approved.
Fix compiletest windows path finding with spaces
With `(?x)` enabled spaces are ignored unless you escape them, so the space wasn't being added to the character class
I don't think this makes any difference to the current test suite, but it could save someone a headache in the future
In the current documentation, it's not specified that when creating
a Command, the .exe extension can be omitted for Windows executables.
However, for other types of executable files like .bat or .cmd,
the complete filename including the extension must be provided.
I encountered it by noticing that `Command::new("wt").spawn().unwrap()`
succeeds on my machine while `Command::new("code").spawn().unwrap()`
panics. Turns out VS Code's entrypoint is .cmd file.
`resolve_exe` method mentions this behaviour in a comment[1], but it
makes sense to mention it at more visible place.
I've added this clarification to the documentation, which should
make it more accurate and helpful for Rust developers
working on the Windows platform.
[1] e7fda447e7/library/std/src/sys/windows/process.rs (L425)
Safe Transmute: Fix ICE (due to UnevaluatedConst)
This patch updates the code that looks at the `Assume` type when evaluating if transmutation is possible. An ICE was being triggered in the case that the `Assume` parameter contained an unevaluated const (in this test case, due to a function with missing parameter names).
Fixes#110892
