Rollup of 6 pull requests #130312
Merged
Rollup of 6 pull requests #130312
Conversation
This file contains 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
The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219 [1], one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium. Because: * we do not want to ask users to recompile std if they are to build such software, * objects compiled with larger code models can be linked with those with smaller code models without problems, and * the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB, it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak. [1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models Co-authored-by: WANG Rui <wangrui@loongson.cn>
No analysis needs `Copy`, and `MaybeBorrowedLocals` is the only analysis that needs `Clone`. In `locals_live_across_suspend_points` it gets cloned so it can be used within a `MaybeRequiresStorage`.
Because that's what it is; no point having a different name for it.
…lints This reverts the part of commit 19908ff in subdirectory src/tools/clippy/clippy_lints.
…should point at the called method (eg Fn::call_once), not the underlying callee. Fixes 128848
Fix crash when labeling arguments for call_once and friends When calling a method on Fn* traits explicitly, argument diagnostics should point at the called method (eg Fn::call_once), not the underlying callee. This PR makes 3 main changes: * It uses TupleArguments to detect if the user called a Fn* method directly (`my_fn.call_once(…)`) or implicitly (`my_fn(…)`). If it was explicit, argument diagnostics should point at the call_once method, not the underlying callable. * The previous state was causing confusion between the two arguments lists (which could be different lengths), causing an out-of-bounds slice indexing in rust-lang#128848. I added a length assert to capture the requirement in case this regresses or happens in another case. * Unfortunately, this assert tripped when the required arguments information was not available (`self.get_hir_params_with_generics` was returning an empty Vec), so I've updated that to return None when that information is not available. (cc `@strottos` if you have any comments, since you added this function in rust-lang#121595) Sorry this causes a bunch of indentation changes, recommend reviewing [ignoring whitespace](https://github.com/rust-lang/rust/pull/129320/files?w=1).) This is my first rustc PR, so please call out if you'd like this split into more commits (or PRs), style nits, etc. I will add a few comments/questions inline. Thank you! Fixes rust-lang#128848
…iler-errors target: default to the medium code model on LoongArch targets The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219 [1], one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium. Because: * we do not want to ask users to recompile std if they are to build such software, * objects compiled with larger code models can be linked with those with smaller code models without problems, and * the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB, it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak. Relands [2]: rust-lang#120661 [1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models [2]: rust-lang#121289 (comment)
…jgillot Dataflow cleanups r? `@cjgillot`
…rrors Add set_dcx to ParseSess After [this](rust-lang#126623) PR was merged, it is no longer possible to inject one's own `Emitter` in the way [described in the Compiler Development Guide](https://rustc-dev-guide.rust-lang.org/rustc-driver-getting-diagnostics.html). The reason is that the `dcx` field in `ParseSess` is no longer public, so it is not possible to update the `dcx` field with a `DiagCtxt` that contains one's own `Emitter` in the `psess_created` callback in `rustc_interface::Config`. The only way I have found to insert my own `DiagCtxt` is by creating an entirely new `ParseSess` and replacing the old one. This is not a good solution as the original `ParseSess` contains fields I would like to keep. (In my case the problem is that I lose the `cfg` and `check-cfg` fields of the original.) The solution proposed in this PR is to add a `set_dcx` method to `ParseSess`. Per my limited understanding of the rustc codebase this should be fine as `set_dcx` requires a mutable reference to `ParseSess`, which is as far as I know only available in the `psess_created` callback (outside of `rustc_interface::run_compiler`). If this PR is accepted, I will create a new PR to update the aforementioned example in the Compiler Development Guide.
…ons, r=compiler-errors some fixes for clashing_extern_declarations lint There were two issues with the clashing_extern_declarations lint: - It would accept non-`repr(C)` structs as compatible with each other by comparing their fields in declaration order, but the fields could have different memory order (and with `-Zrandomize-layout`, this can really happen). - It would accept two types as compatible if `compare_layouts` returns `true`, but that function actually just compared the *ABI*, not the fully layout -- and all sized structs with more than 2 fields have the same ABI (`Abi::Aggregate`), so this missed a *lot* of cases. We don't currently have a clear spec for what we *want* to consider "clashing" and what is fine, so I otherwise kept the original logic. I hope to have a t-lang discussion about this at some point. But meanwhile, these changes seem like clear bugfixes.
…at_bits_conv, r=flip1995 Clippy: consider msrv for const context for const_float_bits_conv When `const_float_bits_conv` was stabilized for 1.83.0, clippy lints started to be triggered in const context ignoring MSRV. This PR makes the lints trigger in const context only when the MSRV meets 1.83.0. Fixes rust-lang/rust-clippy#13383.
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=6 |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 13, 2024
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#129320 (Fix crash when labeling arguments for call_once and friends) - rust-lang#130266 (target: default to the medium code model on LoongArch targets) - rust-lang#130297 (Dataflow cleanups) - rust-lang#130299 (Add set_dcx to ParseSess) - rust-lang#130301 (some fixes for clashing_extern_declarations lint) - rust-lang#130305 (Clippy: consider msrv for const context for const_float_bits_conv) r? `@ghost` `@rustbot` modify labels: rollup
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
@bors retry |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 0307e401c2 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (0609062): comparison URL. Overall result: ❌ regressions - no action needed@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)Results (primary 2.5%)This 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.
CyclesResults (secondary -6.3%)This 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: 756.444s -> 759.315s (0.38%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup