Rollup of 14 pull requests#158971
Closed
JonathanBrouwer wants to merge 51 commits into
Closed
Conversation
used as `GlobalAlloc`s
…st from delegation parent
`--output-format=json` does a few different things:
- By itself, it emits a JSON representation of a crate's API ("IR
JSON").
- When used with `--show-coverage`, it prints the doc coverage as JSON,
instead of an ASCII table ("Coverage JSON").
These two cases need to be handled entirely differently. There's no
overlapping code, they just are called the same way.
By making these separate variants, we don't need to check the
`show_coverage` variable each time we check `is_json`, which makes it
harder to write a bug that checks for IR JSON, and accidentally happens in
coverage JSON too.
Also, as a driveby, improves some instability error messages, and cleans
up their tests, and adds other related tests.
The `wasm32-unknown-emscripten` target uses the argc/argv form of main but emitted the entry point under the raw name `main`. That links on the default entry path (emscripten calls it via `callMain`), but fails on entry paths that reference the mangled symbol directly from wasm. In particular `-sPROXY_TO_PTHREAD` links `crt1_proxy_main.o`, whose call chain bottoms out at `__main_argc_argv`, so linking a Rust binary fails with:
```
wasm-ld: error: crt1_proxy_main.o: undefined symbol: main
```
This sets `entry_name = "__main_argc_argv"` so the entry point is emitted under the C-ABI name emscripten's crt/libc expects, and then works in both cases.
The JS-visible name of the entry point stays `_main`, since emscripten bridges `_main` to the wasm `__main_argc_argv` export internally (whereas it wouldn't for `___main_argc_argv`).
For small repr(C) aggregates with padding, direct constant
initialization can still lower into field-wise construction plus
memcpy. That leaves the backend to rediscover that the whole object
is a single constant byte pattern.
This is especially visible for non-zero constant aggregates. Instead
of materializing them as separate field stores, we want codegen_ssa to
emit the packed value directly. For example, a value like
InnerPadded { a: 0, b: 1, c: 0 }
can otherwise lower to something like
store i16 0, ptr %val, align 4
store i8 1, ptr %val_plus_2, align 2
store i32 0, ptr %val_plus_4, align 4
call void @llvm.memcpy(..., ptr %val, ...)
while this change produces
store i64 65536, ptr %val, align 4
call void @llvm.memcpy(..., ptr %val, ...)
Why not solve this in LLVM?
At the problematic lowering point, rustc still knows that the MIR
aggregate is small and fully constant. LLVM only sees a lowered stack
temporary built from per-field stores and then copied out. Recovering
that packed constant there would require rediscovering front-end
aggregate semantics after lowering, so emitting the packed store in
rustc is the simpler and more local fix.
Why not keep the previous typed-copy approach?
An earlier approach zeroed padding on typed copies whose source could
be traced back to a constant assignment. That helped some cases, but it
also widened the optimization to runtime copy paths and could introduce
extra runtime stores purely to maintain padding knowledge. That is not
an acceptable tradeoff here.
Keep the scope narrow instead: only handle direct MIR aggregates whose
fields are all constants, and pack them according to the target
endianness before emitting a single integer store.
Add a focused codegen test covering the original PR 157690 entry
points together with non-zero constant cases. The test uses
-Cno-prepopulate-passes so it checks the immediate-store shape directly
at rustc codegen time, instead of depending on later LLVM store
merging.
This prints generics parameters when these are concrete Adt generics args. A lint is emitted we try to format a generic that is found anywhere. Moreover, generics parameters that are ty infer vars are no longer displayed "as-is", it is not clear and might be confusing, in this specific case the name of the generic parameter will be displayed instead.
…, r=bjorn3
Emit the emscripten entry point as `__main_argc_argv`
Fixes support for building `wasm32-unknown-emscripten` under the `-sPROXY_TO_PTHREAD` linking option.
The `wasm32-unknown-emscripten` target uses the argc/argv form of main but emitted the entry point under the raw name `main`. That links on the default entry path (emscripten calls it via `callMain`), but fails on entry paths that reference the mangled symbol directly from wasm. In particular `-sPROXY_TO_PTHREAD` links `crt1_proxy_main.o`, whose call chain bottoms out at `__main_argc_argv`, so linking a Rust binary fails with:
```
wasm-ld: error: crt1_proxy_main.o: undefined symbol: main
```
This sets `entry_name = "__main_argc_argv"` so the entry point is emitted under the C-ABI name emscripten's crt/libc expects, and then works in both cases.
The JS-visible name of the entry point stays `_main`, since emscripten bridges `_main` to the wasm `__main_argc_argv` export internally (whereas it wouldn't for `___main_argc_argv`).
Library support for aarch64-unknown-linux-pauthtest target This is a follow up to rust-lang#155722, adding library support for the target.
…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend
…_arguments, r=mejrs Improve generic parameters handling for #[diagnostic::on_const] cc rust-lang#155570 This Improves generic parameters handling for #[diagnostic::on_const] This is done by printing generics parameters when these are concrete Adt generics args. A lint is emitted we try to format a generic that is found anywhere. Moreover, generics parameters that are ty infer vars are no longer displayed "as-is", it is not clear and might be confusing, in this specific case the name of the generic parameter will be displayed instead. I will need some help for displaying the `Z`parameter correctly. From what I have understood, it is an `ty::Infer(ty::TyVar(_))` that is not correctly displayed via `self.tcx.short_string()` (in `on_unimplemented_components()`), or even not correctly inferred via `self.infcx.ty_to_string()`. EDIT: general descrition updated
…tes-ice, r=BoxyUwU delegation: do not always inherit `ConstArgHasType` predicates The explanation can be found in comment in `inherit_predicates_for_delegation_item`. So the problem is that we have two `ConstArgHasType` predicates in `param_env` which tell that a single const has different types. But the function `find_const_ty_from_env` panics in this situation. This assert is here for a long time, and I do not have enough knowledge to say if it is correct or not, however I have thoughts that having contradictory predicates should not lead to panic, instead an error from trait solver or whatever engine that solves those predicates should be reported. Do not want to dive too deep into researching and possibly rewriting `find_const_ty_from_env`, so fixed it on delegation level. Fixes rust-lang#158675. Part of rust-lang#118212. r? @petrochenkov
…=hanna-kruppe
Simplify `Option::into_flat_iter` signature
```diff
impl<T: IntoIterator> Option<T> {
- pub fn into_flat_iter<A>(self) -> OptionFlatten<A>
- where
- T: IntoIterator<IntoIter = A>,
+ pub fn into_flat_iter(self) -> OptionFlatten<T::IntoIter> {
}
```
This is marked as an unresolved question (rust-lang#148441, rust-lang#148487 (comment)), but I cannot come up with any reason to have this generic.
rustbot
added
A-attributes
Contributor
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
Contributor
|
⌛ Trying commit 0a5274b with merge cca382e… To cancel the try build, run the command Workflow: https://github.com/rust-lang/rust/actions/runs/28968779355 |
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 8, 2026
Rollup of 14 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1 try-job: i686-msvc-2
Contributor
Author
|
@bors try cancel |
rust-bors
Bot
added
the
S-waiting-on-author
Contributor
|
This pull request was unapproved due to being closed. |
rust-bors
Bot
removed
the
S-waiting-on-bors
Contributor
|
Try build cancelled. Cancelled workflows: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
std::io::Writetocore::io#158541 (Movestd::io::Writetocore::io)--output-format=jsoncoverage and ir differently #154445 (rustdoc: Represent--output-format=jsoncoverage and ir differently)Allocators to be used as#[global_allocator]s #157153 (allowAllocators to be used as#[global_allocator]s)x perf compare#158932 (Do not build the compiler when invokingx perf compare)__main_argc_argv#158937 (Emit the emscripten entry point as__main_argc_argv)ConstArgHasTypepredicates #158722 (delegation: do not always inheritConstArgHasTypepredicates)Option::into_flat_itersignature #158741 (SimplifyOption::into_flat_itersignature)r? @ghost
Create a similar rollup