This commit reverts a change made in #111425.
It was believed that this change was necessary for implementing type privacy lints, but #111801 showed that it was not necessary.
Quite opposite, the revert fixes some issues.
Fix explicit-outlives-requirements lint span
Fixes#105150 which caused the span reported by the explicit-outlives-requirements lint to be incorrect when
1) the lint should suggest the entire where clause to be removed and
2) there are inline bounds present that are not inferable outlives requirements
In particular, this would cause rustfix to leave a dangling empty where clause.
Error on unconstrained lifetime in RPITIT
Fixes#109468
The only thing is that I had to split `tests/ui/impl-trait/in-trait/method-signature-matches.rs` into a bunch of different revisions because some error aren't being emitted if all the different examples are all together in one file 🤔
r? `@oli-obk` just because i know you'll review it, feel free to re-roll
Properly check associated consts for infer placeholders
We only reported an error if it was in a "suggestable" position (according to `is_suggestable_infer_ty`) -- this isn't correct for infer tys that can show up in other places in the constant's type, like behind a dyn trait.
fixes#112491
Improve docs/clean up negative overlap functions
Clean up some functions in ways that should not affect behavior, change some names to be clearer (`negative_impl` and `implicit_negative` are not really clear imo), and add some documentation examples.
r? `@spastorino`
Introduce a `Stable` trait to translate MIR to SMIR
This PR introduces a trait `Stable` which defines a type `T` and a `stable()` method to convert the current type to its stable MIR version.
This change is just an implementation detail, and I wanted to get some feedback to whether it would be cleaner than having the `rustc_<type>_to_<type>()` methods for every type we translate to SMIR.
r? `@oli-obk`
r? `@spastorino`
Don't print unsupported split-debuginfo modes with `-Zunstable-options`
Currently unsupported `split-debuginfo` options are enabled by `-Zunstable-options`, for projects that have `-Zunstable-options` for other reasons this can be [an unexpected interaction](https://github.com/rust-lang/rust-clippy/pull/10516#issuecomment-1562604764)
This PR makes it so that `--print split-debuginfo -Zunstable-options` doesn't print unsupported modes, so that a cargo config of e.g.
```toml
[profile.dev]
split-debuginfo = "unpacked"
```
Would not cause an unsupported mode to be enabled on `x86_64-pc-windows-msvc`
loongarch64-none*: Remove environment component from llvm target
A warning is reported when the LLVM triple-implied ABI conflicts with the provided target-abi.
```
warning: triple-implied ABI conflicts with provided target-abi ‘lp64s', using target-abi
```
Specifically, the ABI hint comes from the environment component of the triple. When only the target-abi is provided and no environment, there is no conflict. This PR removes the environment component from the LLVM target name of the `loongarch64-unknown-none-softfloat` target.
Collect VTable stats & add `-Zprint-vtable-sizes`
This is a bit hacky/buggy, but I'm not entirely sure how to fix it, so I want to ask reviewers for help...
To try this, use either of those:
- `cargo clean && RUSTFLAGS="-Zprint-vtable-sizes" cargo +toolchain b`
- `cargo clean && cargo rustc +toolchain -Zprint-vtable-sizes`
- `rustc +toolchain -Zprint-vtable-sizes ./file.rs`
Safe Transmute: Enable handling references
This patch enables support for references in Safe Transmute, by generating nested obligations during trait selection. Specifically, when we call `confirm_transmutability_candidate(...)`, we now recursively traverse the `rustc_transmute::Answer` tree and create obligations for all the `Answer` variants, some of which include multiple nested `Answer`s.
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
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.
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.
loongarch64-unknown-none*: Set default relocation model to static
This PR sets the default relocation model to `static` for `loongarch64-unknown-none*` targets. This change aims to streamline the development of the bare-metal project by removing the need for the executable program loader to implement relocation.
- Create `Answer` type that is not just a type alias of `Result`
- Remove a usage of `map_layouts` to make the code easier to read
- Don't hide errors related to Unknown Layout when computing transmutability
