Rollup of 10 pull requests#153304
Conversation
The manual `DynSend` implementation for `AtomicPtr` blocks the auto-implementation for other atomic primitives since they forward to the same `Atomic<T>` type now. This breakage cannot occur in user code as it depends on `DynSend` being a custom auto-trait.
... and remove some unused diagnostic items.
`rustc_with_all_queries` currently provides information about all queries. Also, a caller can provide an ad hoc list of extra non-queries. This is used by `define_queries` for non-query dep kinds: `Null`, `Red`, etc. This is pretty hacky. This commit changes `rustc_with_all_queries` so that the non-queries information is available to all callers. (Some callers ignore the non-query information.) This is done by adding `non_query` entries to the primary list of queries in `rustc_queries!`.
Currently `define_dep_nodes` produces a macro `make_dep_kind_array` that encodes the names of non-queries followed by queries. This macro is used by `make_dep_kind_vtables` to make the full array of vtables, by referring to vtable constructor functions that are put into `mod _dep_kind_vtable_ctors`. Pretty weird! This commit takes advantage of the previous commit's changes to `rustc_with_all_queries`, which makes both query and non-query information available. A new call to `rustc_with_all_queries` is used to construct the vtable array. (This moves some dep_kind_vtable code from `plumbing.rs` to `dep_kind_vtables.rs`, which is good.) It's straightforward now with iterator chaining, and `mod _dep_kind_vtable_ctors` is no longer needed.
"i.e." is short for the Latin "id est" and thus both letters should be followed by periods.
and in particular for naked functions in that scenario
The uwtable attribute does not get emitted on targets that don't have unwinding tables, such as x86_64-unknown-hermit.
Hermit does not yet support spawning processes.
add tests for thumb interworking fixes rust-lang#151946 thumb programs (using a 16-bit instruction encoding) can call arm (32-bit instruction encoding) code. Doing so requires switching from thumb mode to arm mode, executing, then switching back. Test that this happens correctly, in particular for naked functions. cc @thejpster can you confirm the output looks good here and that we're testing all of the relevant things r? jieyouxu because this is doing some interesting things testing-wise I believe that we need run-make here because we need to look at the assembly after the linker has run. It will correct calls from thumb to arm: depending on the thumb version this either uses a special instruction or inserts a call to a thunk that handles switching between thumb and arm mode.
…s, r=nikic Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs` It was discovered that the FileCheck tests when performing an `Option::or` operation on a slice was failing when tested on a big endian host. The compiler explorer link is here outlining the codegen output differences - https://rust.godbolt.org/z/qdE7d3G4f This MR relaxes the constraints for the `*slice_u8` variants of the test (by changing `CHECK-NEXT` to `CHECK-DAG`), whilst still maintaining the check for the necessary `or` logic. Huge thanks to @Gelbpunkt for identifying this issue! It has been confirmed that this fix passes on a big endian target now as well. Closes rust-lang#151718
…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixes rust-lang#151957
…ratt core: make atomic primitives type aliases of `Atomic<T>` Tracking issue: rust-lang#130539 This makes `AtomicI32` and friends type aliases of `Atomic<T>` by encoding their alignment requirements via the use of an internal `Storage` associated type. This is also used to encode that `AtomicBool` store a `u8` internally. Modulo the `Send`/`Sync` implementations, this PR does not move any trait implementations, methods or associated functions – I'll leave that for another PR.
…ueries, r=Zalathar Rejig `rustc_with_all_queries!` There are three things relating to `rustc_with_all_queries!` that have been bugging me. - `rustc_with_all_queries!`'s ability to receive `extra_fake_queries` lines like `[] fn Null(()) -> (),` where the only real thing is the `Null`, and everything is just pretending to be a normal query, ugh. - `make_dep_kind_array!`: a macro produced by one macro (`define_dep_nodes!`) and used by another macro (`define_queries!`) in another crate, ugh. - The `_dep_kind_vtable_ctors` module, which is a special module with no actual code that serves just a way of collecting vtable constructors from two different places so they can be referred to by `make_dep_kind_array!`, ugh. By making some adjustments to how `rustc_with_all_queries!` works, all three of these things are eliminated. r? @Zalathar
…tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmann Fixes rust-lang#153144. So it turns out rust-lang#153018 had a sneaky behavior change in the way tuples are handled and the old behavior wasn't tested. Consider these tuples: ```rust ((), ()); ((), 1); ``` Neither of them is `must_use`, so they are potential candidates for `unused_results`. So the question is whatever said tuples are considered "trivial" and thus if they end up emitting `unused_results` or not. Here is a comparison table between PRs: <table> <tr><td>stable</td><td>After rust-lang#153018</td><td>After this PR</td></tr><tr><td> ```rust ((), ()); // trivial ((), 1); // trivial ``` </td> <td> ```rust ((), ()); //~ warn: unused_results ((), 1); //~ warn: unused_results ``` </td> <td> ```rust ((), ()); // trivial ((), 1); //~ warn: unused_results ``` </td> </tr> <tr> <td> tuples are trivial if **any** of their fields are trivial </td> <td> tuples are never trivial </td> <td> tuples are trivial if **all** of their fields are trivial </td> </tr> </table>
vec/mod.rs: add missing period in "ie." in docs "i.e." is short for the Latin "id est" and thus both letters should be followed by periods.
…onal, r=jieyouxu tests: codegen-llvm: vec-calloc: do not require the uwtable attribute The `uwtable` attribute does not get emitted on targets that don't have unwinding tables, such as `x86_64-unknown-hermit`.
…t, r=joboet library: std: process: skip tests on Hermit Hermit does not yet support spawning processes.
…obzol Do not ping kobzol on rustc-dev-guide changes I don't really react to those pings anyway.
|
@bors r+ rollup=never p=5 |
This comment has been minimized.
This comment has been minimized.
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 8ddf4ef (parent) -> ec818fd (this PR) Test differencesShow 1601 test diffsStage 1
Stage 2
Additionally, 1588 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard ec818fda361ca216eb186f5cf45131bd9c776bb4 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (ec818fd): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 1.3%, secondary 1.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 5.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.1%, secondary 0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 480.113s -> 480.002s (-0.02%) |
Successful merges:
multiple-option-or-permutations.rs#151780 (Updated slice tests to pass for big endian hosts formultiple-option-or-permutations.rs)Atomic<T>#153015 (core: make atomic primitives type aliases ofAtomic<T>)rustc_with_all_queries!#153161 (Rejigrustc_with_all_queries!)unused_resultslint for tuples of "trivial" types #153191 ( don't emitunused_resultslint for tuples of "trivial" types )r? @ghost
Create a similar rollup