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.
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
Add windows_sys type definitions for ARM32 manually
`windows_sys` bindings do not include platform-specific type definitions for ARM 32 architecture, so it breaks `thumbv7a-pc-windows-msvc` and `thumbv7a-uwp-windows-msvc` targets. This PR tries to add them back by manually inserting them together with the generated ones.
`WSADATA` is copied from the generated definition for `x86`. `CONTEXT` is copied from the definition before `windows_sys` is introduced (which is just an empty enum): 4a18324a4d/library/std/src/sys/windows/c.rs (L802).
Fixes#112265.
Suggest using `ptr::null_mut` when user provided `ptr::null` to a function expecting `ptr::null_mut`
```
error[E0308]: mismatched types
--> $DIR/ptr-null-mutability-suggestions.rs:9:24
|
LL | expecting_null_mut(ptr::null());
| ------------------ ^^^^^^^^^^^
| | |
| | types differ in mutability
| | help: consider using `core::ptr::null_mut` instead: `core::ptr::null_mut()`
| arguments to this function are incorrect
|
= note: expected raw pointer `*mut u8`
found raw pointer `*const _`
note: function defined here
--> $DIR/ptr-null-mutability-suggestions.rs:6:4
|
LL | fn expecting_null_mut(_: *mut u8) {}
| ^^^^^^^^^^^^^^^^^^ ----------
```
Closes#85184.
implement stdout streaming in `render_tests::Renderer`
This way, we can show the test dot characters on the console immediately, without having to wait for the entire line to finish.
cc `@GuillaumeGomez`
- Either explicitly annotate `let x: () = expr;` where `x` has unit
type, or remove the unit binding to leave only `expr;` instead.
- Fix disjoint-capture-in-same-closure test
