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`
Update runtime guarantee for `select_nth_unstable`
#106933 changed the runtime guarantee for `select_nth_unstable` from O(n) to O(n log n), since the old guarantee wasn't actually met by the implementation at the time. Now with #107522, `select_nth_unstable` should be truly linear in runtime, so we can revert its runtime guarantee to O(n). Since #106933 was considered a bug fix, this will probably need an FCP because it counts as a new API guarantee.
r? `@Amanieu`
Stabilize String::leak
Stabilizes the following API:
```Rust
impl String {
pub fn leak(self) -> &'static mut str;
}
```
closes#102929
blocked by having an FCP for stabilization.
Implement `TryFrom<&OsStr>` for `&str`
Recently when trying to work with `&OsStr` I was surprised to find this `impl` missing.
Since the `to_str` method already existed the actual implementation is fairly non-controversial, except for maybe the choice of the error type. I chose an opaque error here instead of something like `std::str::Utf8Error`, since that would already make a number of assumption about the underlying implementation of `OsStr`.
As this is a trait implementation, it is insta-stable, if I'm not mistaken?
Either way this will need an FCP.
I chose "1.64.0" as the version, since this is unlikely to land before the beta cut-off.
`@rustbot` modify labels: +T-libs-api
API Change Proposal: rust-lang/rust#99031 (accepted)
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
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.
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.
Adjust UI tests for `unit_bindings` lint
- Explicitly annotate `let x: () = expr;` where `x` has unit type, or remove the unit binding to leave only `expr;` instead.
- Use `let () = init;` or `let pat = ();` where appropriate.
- Fix disjoint-capture-in-same-closure test which wasn't actually testing a closure: `tests/ui/closures/2229_closure_analysis/run_pass/disjoint-capture-in-same-closure.rs`.
Note that unfortunately there's *a lot* of UI tests, there are a couple of places where I may have left something like `let (): ()` (this is not needed but is left over from an ealier version of the lint) which is bad style.
This PR is to help with the `unit_bindings` lint at #112380.
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.
Make BinaryHeap parametric over Allocator
Tracking issue: #32838
Related: https://github.com/rust-lang/wg-allocators/issues/7
This parametrizes `BinaryHeap` with `A`, similarly to how other collections are parametrized.
A couple things I left out:
```
BinaryHeap::append
Currently requires both structures to have the same allocator type. Could
change, but depends on Vec::append, which has the same constraints.
impl<T: Ord> Default for BinaryHeap<T>
Not parametrized, because there's nowhere to conjure the allocator from.
impl<T: Ord> FromIterator<T> for BinaryHeap<T>
Not parametrized, because there's nowhere to conjure the allocator from.
impl<T: Ord, const N: usize> From<[T; N]> for BinaryHeap<T>
Not parametrized, because there's nowhere to conjure the allocator from.
unsafe impl<I> AsVecIntoIter for IntoIter<I>
AsVecIntoIter is not allocator aware, and I didn't dare change it without guidance. Is this something important?
```
I've seen very few tests for allocator_api in general, but I'd like to at least test this on some usage code in my projects before moving forward.
EDIT: Updated the list of impls and functions that are not affected by this. `BinaryHeap` no longer has a `SpecExtend` impl, and prior work made implementing `Extend` possible.
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.
- 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
Rollup of 4 pull requests
Successful merges:
- #112302 (Suggest using `ptr::null_mut` when user provided `ptr::null` to a function expecting `ptr::null_mut`)
- #112416 (Fix debug ICE for extern type with where clauses)
- #112527 (Add windows_sys type definitions for ARM32 manually)
- #112546 (new solver: extend assert to other aliases)
r? `@ghost`
`@rustbot` modify labels: rollup
