Rollup of 5 pull requests
Successful merges:
- #112197 (Erase regions even if normalization fails in writeback (in new solver))
- #112495 (fix(resolve): update shadowed_glob more precision)
- #112520 (Fix the overflow issue for transmute_generic_consts)
- #112571 (rustdoc-search: search never type with `!`)
- #112581 ([rustdoc] Fix URL encoding of % sign)
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc-search: search never type with `!`
This feature extends rustdoc to support the syntax that most users will naturally attempt to use to search for diverging functions. Part of #60485
It's already possible to do this search with `primitive:never`, but that's not what the Rust language itself uses, so nobody will try it if they aren't told or helped along.
fix(resolve): update shadowed_glob more precision
- Fixes#109153
- Fixes#109962
## Why does it panic?
We use #109153 as an illustration.
The process of `resolve_imports` is:
| Iter | resolve | resolution of **`(Mod(root), Ident(bar) in type ns)`** |
| - | - | - |
| 0 | `use foo::*` | `binding` -> foo::bar, `shallowed_glob` -> `None` |
| 1 | `use bar::bar` | `binding` -> foo::bar::bar, `shallowed_glob` -> foo::bar |
| 2 | `use bar::*` | `binding` -> foo::bar::bar, `shallowed_glob` -> foo::bar::bar::bar |
So during `finalize_import`, the `root::bar` in `use bar::bar` had been pointed to `foo::bar::bar::bar`, which is different from the `initial_module` valued of `foo::bar`, therefore, the panic had been triggered.
## Try to solve it
~I think #109153 should check-pass rather than throw an ambiguous error. Following this idea, there are two ways to solve this problem:~
~1. Give up the `initial_module` and update `import.imported_module` after each resolution update. However, I think this method may have too much impact.~
~2. Do not update the `shadowed_glob` when it is defined.~
~To be honest, I am not sure if this is the right way to solve this ICE. Perhaps there is a better resolution.~
Edit: we had made the `resolution.shadowed_glob` update more detailed.
r? `@petrochenkov`
Introduce a minimum CGU size in non-incremental builds.
Because tiny CGUs slow down compilation *and* result in worse generated code.
r? `@wesleywiser`
Because tiny CGUs make compilation less efficient *and* result in worse
generated code.
We don't do this when the number of CGUs is explicitly given, because
there are times when the requested number is very important, as
described in some comments within the commit. So the commit also
introduces a `CodegenUnits` type that distinguishes between default
values and user-specified values.
This change has a roughly neutral effect on walltimes across the
rustc-perf benchmarks; there are some speedups and some slowdowns. But
it has significant wins for most other metrics on numerous benchmarks,
including instruction counts, cycles, binary size, and max-rss. It also
reduces parallelism, which is good for reducing jobserver competition
when multiple rustc processes are running at the same time. It's smaller
benchmarks that benefit the most; larger benchmarks already have CGUs
that are all larger than the minimum size.
Here are some example before/after CGU sizes for opt builds.
- html5ever
- CGUs: 16, mean size: 1196.1, sizes: [3908, 2992, 1706, 1652, 1572,
1136, 1045, 948, 946, 938, 579, 471, 443, 327, 286, 189]
- CGUs: 4, mean size: 4396.0, sizes: [6706, 3908, 3490, 3480]
- libc
- CGUs: 12, mean size: 35.3, sizes: [163, 93, 58, 53, 37, 8, 2 (x6)]
- CGUs: 1, mean size: 424.0, sizes: [424]
- tt-muncher
- CGUs: 5, mean size: 1819.4, sizes: [8508, 350, 198, 34, 7]
- CGUs: 1, mean size: 9075.0, sizes: [9075]
Note that CGUs of size 100,000+ aren't unusual in larger programs.
Make struct layout not depend on unsizeable tail
fixes (after backport) https://github.com/rust-lang/rust/issues/112048
Since unsizing `Ptr<Foo<T>>` -> `Ptr<Foo<U>` just copies the pointer and adds the metadata, the layout of `Foo` must not depend on niches in and alignment of the tail `T`.
Nominating for beta 1.71, because it will have this issue: `@rustbot` label beta-nominated
Ignore `core`, `alloc` and `test` tests that require unwinding on `-C panic=abort`
Some of the tests for `core` and `alloc` require unwinding through their use of `catch_unwind`. These tests fail when testing using `-C panic=abort` (in my case through a target without unwinding support, and `-Z panic-abort-tests`), while they should be ignored as they don't indicate a failure.
This PR marks all of these tests with this attribute:
```rust
#[cfg_attr(not(panic = "unwind"), ignore = "test requires unwinding support")]
```
I'm not aware of a way to test this on rust-lang/rust's CI, as we don't test any target with `-C panic=abort`, but I tested this locally on a Ferrocene target and it does indeed make the test suite pass.
Ignore `core`, `alloc` and `test` tests that require unwinding on `-C panic=abort`
Some of the tests for `core` and `alloc` require unwinding through their use of `catch_unwind`. These tests fail when testing using `-C panic=abort` (in my case through a target without unwinding support, and `-Z panic-abort-tests`), while they should be ignored as they don't indicate a failure.
This PR marks all of these tests with this attribute:
```rust
#[cfg_attr(not(panic = "unwind"), ignore = "test requires unwinding support")]
```
I'm not aware of a way to test this on rust-lang/rust's CI, as we don't test any target with `-C panic=abort`, but I tested this locally on a Ferrocene target and it does indeed make the test suite pass.
When building as part of rust, the sysroot source dir is symlinked to
the main source dir, which contains the build dir to which we are likely
copying.
Add MVP suggestion for `unsafe_op_in_unsafe_fn`
Rebase of https://github.com/rust-lang/rust/pull/99827
cc tracking issue https://github.com/rust-lang/rust/issues/71668
No real changes since the original PR, just migrated the new suggestion to use fluent messages and added a couple more testcases, AFAICT from the discussion there were no outstanding changes requested.
