Rollup of 8 pull requests #113370
Rollup of 8 pull requests #113370
Conversation
This effectively inlines most of `FunctionCx::codegen_coverage` into the LLVM implementation of `CoverageInfoBuilderMethods`.
…d it These methods are only ever called from within `rustc_codegen_llvm`, so they can just be declared there as well.
rust-installer & rls: remove exclusion from rustfmt & tidy <strike>based on rust-lang#112884</strike> `rust-installer` and `rls` no longer submodules, but not removed from exclude list for rustfmt and tidy, preventing running fmt and lints on them.
-Ztrait-solver=next: stop depending on old solver removes the final dependencies on the old solver when `-Ztrait-solver=next` is enabled.
…iler-errors `TypeParameterDefinition` always require a `DefId` the `None` case never actually reaches diagnostics so it feels better for diagnostics to be able to rely on the `DefId` being there, cc rust-lang#113310
…etrochenkov,BoxyUwU Add some extra information to opaque type cycle errors Plus a bunch of cleanups. This should help users debug query cycles due to auto trait checking. We'll probably want to fix cycle errors in most (or all?) cases by looking at the current item's hidden types (new solver does this), and by delaying the auto trait checks to after typeck.
…r=oli-obk Move `ty::ConstKind` to `rustc_type_ir` Needed this in another PR for custom debug impls, and this will also be required to move the new solver into a separate crate that does not use `TyCtxt` so that r-a and friends can depend on the trait solver. Rebased on top of rust-lang#113325, only the second and third commits needs reviewing
…-specializing, r=lcnr Winnow specialized impls during selection in new solver We need to be able to winnow impls that are specialized by more specific impls in order for codegen to be able to proceed. r? ``@lcnr``
Move most coverage code out of `rustc_codegen_ssa` *This is one step in my larger coverage refactoring ambitions described at <https://github.com/rust-lang/compiler-team/issues/645>.* The backend implementation of coverage instrumentation was originally split between SSA and LLVM, perhaps in the hopes that it could be used by other backends. In practice, this split mostly just makes the coverage implementation harder to navigate and harder to modify. It seems unlikely that any backend will actually implement coverage instrumentation in the foreseeable future, especially since many parts of the existing implementation (outside the LLVM backend) are heavily tied to the specific details of LLVM's coverage instrumentation features. The current shared implementation of `codegen_coverage` is heavily tied to the details of `StatementKind::Coverage`, which makes those details difficult to change. I have reason to want to change those details as part of future fixes/improvements, so this will reduce the amount of interface churn caused by those later changes. --- This is intended to be a pure refactoring change, with no changes to actual behaviour. All of the “added” code has really just been moved from other files.
Add support for NetBSD/riscv64 aka. riscv64gc-unknown-netbsd.
|
@bors r+ rollup=never p=8 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: e4cd161006 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (5dac6b3): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 655.622s -> 658.838s (0.49%) |
|
Strange. Hopefully noise? But I started a rust-timer on #113320 (comment) and #113317 (comment). Other PRs don't look like they affected anything? But maybe I overlooked something. |
|
Noise spikes on (In case you don't know: you don't have to launch the perf runs on the rolled up PR's individual page, you can also launch them here in this rollup, e.g. so that all your investigation is in the same place, and it's a bit more convenient than going to multiple pages) |
|
Huh, well looks like #113320 (comment) may be the culprit? cc @oli-obk Or else someone should look at those results and conclude they're noise. |
|
I should try reverting the entire PR, will do that tomorrow. |
|
I got you, hopefully you'll have #113587's results ready for breakfast. |
|
Thanks ❤️ Looks like there is indeed no regression from that PR and it was all noise?! Unless something changed to solidify the regression and now we can't undo it (which would speak for inliner noise) |
|
Very confusing indeed, the
Maybe some noise when testing individual PRs has prevented us from seeing the correct PR introducing it, or it's a combination of multiple PRs in this rollup that is causing the issue. |
Successful merges:
TypeParameterDefinitionalways require aDefId#113319 (TypeParameterDefinitionalways require aDefId)ty::ConstKindtorustc_type_ir#113321 (Movety::ConstKindtorustc_type_ir)rustc_codegen_ssa#113355 (Move most coverage code out ofrustc_codegen_ssa)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup