Automatic Rustup #3885
Merged
Automatic Rustup #3885
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Add -Z small-data-threshold This flag allows specifying the threshold size above which LLVM should not consider placing small objects in a `.sdata` or `.sbss` section. Support is indicated in the target options via the small-data-threshold-support target option, which can indicate either an LLVM argument or an LLVM module flag. To avoid duplicate specifications in a large number of targets, the default value for support is DefaultForArch, which is translated to a concrete value according to the target's architecture.
Pass deployment target when linking with CC on Apple targets This PR effectively implements what's also being considered in the `cc` crate [here](rust-lang/cc-rs#1030 (comment)), that is: - When linking macOS targets with CC, pass the `-mmacosx-version-min=.` option to specify the desired deployment target. Also, no longer pass `-m32`/`-m64`, these are redundant since we already pass `-arch`. - When linking with CC on iOS, tvOS, watchOS and visionOS, only pass `-target` (we assume for these targets that CC forwards to Clang). This is required to get the linker to emit the correct `LC_BUILD_VERSION` of the final binary. See rust-lang/rust#129432 for more motivation behind this change. r? compiler CC `@BlackHoleFox`
Revert "Stabilize `-Znext-solver=coherence`" This is a clean revert of #121848, prepared by running: ``` $ git revert 17b322fa69eed7216dccc9f097eb68237cf62234 -m1 ``` Which effectively reverts: * a138a9261536ac2bdbb7c01a8aa9dc7d43299cae, 69fdd1457d367ce4de044e9784e58a38acf3d847, d93e047c9f1b33892a604273ab3931815f5604a1, 1a893ac648e03732aaa8b5371b602ab683970b0d see: https://rust-lang.zulipchat.com/#narrow/stream/364551-t-types.2Ftrait-system-refactor/topic/nalgebra.20hang Closes #130056 r? lcnr
…ss35 Update compiler-builtins to 0.1.125 This commit updates the compiler-builtins crate from 0.1.123 to 0.1.125. The changes in this update are: * rust-lang/compiler-builtins#682 * rust-lang/compiler-builtins#678 * rust-lang/compiler-builtins#685
unify `llvm-bitcode-linker`, `wasm-component-ld` and llvm-tools logics To use the precompiled `ci-rustc` in CI, we need to install `llvm-bitcode-linker` and LLVM tools into ci-rustc's sysroot. Without them some CI pipelines may fail, as shown [here](rust-lang/rust#122709 (comment)). Blocker for rust-lang/rust#122709
Rescope temp lifetime in if-let into IfElse with migration lint Tracking issue #124085 This PR shortens the temporary lifetime to cover only the pattern matching and consequent branch of a `if let`. At the expression location, means that the lifetime is shortened from previously the deepest enclosing block or statement in Edition 2021. This warrants an Edition change. Coming with the Edition change, this patch also implements an edition lint to warn about the change and a safe rewrite suggestion to preserve the 2021 semantics in most cases. Related to #103108. Related crater runs: rust-lang/rust#129466.
…r=michaelwoerister
Don't leave debug locations for constants sitting on the builder indefinitely
Because constants are currently emitted *before* the prologue, leaving the debug location on the IRBuilder spills onto other instructions in the prologue and messes up both line numbers as well as the point LLVM chooses to be the prologue end.
Example LLVM IR (irrelevant IR elided):
Before:
```
define internal { i64, i64 } `@_ZN3tmp3Foo18var_return_opt_try17he02116165b0fc08cE(ptr` align 8 %self) !dbg !347 { start:
%self.dbg.spill = alloca [8 x i8], align 8
%_0 = alloca [16 x i8], align 8
%residual.dbg.spill = alloca [0 x i8], align 1
#dbg_declare(ptr %residual.dbg.spill, !353, !DIExpression(), !357)
store ptr %self, ptr %self.dbg.spill, align 8, !dbg !357
#dbg_declare(ptr %self.dbg.spill, !350, !DIExpression(), !358)
```
After:
```
define internal { i64, i64 } `@_ZN3tmp3Foo18var_return_opt_try17h00b17d08874ddd90E(ptr` align 8 %self) !dbg !347 { start:
%self.dbg.spill = alloca [8 x i8], align 8
%_0 = alloca [16 x i8], align 8
%residual.dbg.spill = alloca [0 x i8], align 1
#dbg_declare(ptr %residual.dbg.spill, !353, !DIExpression(), !357)
store ptr %self, ptr %self.dbg.spill, align 8
#dbg_declare(ptr %self.dbg.spill, !350, !DIExpression(), !358)
```
Note in particular how !357 from %residual.dbg.spill's dbg_declare no longer falls through onto the store to %self.dbg.spill. This fixes argument values at entry when the constant is a ZST (e.g. `<Option as Try>::Residual`). This fixes #130003 (but note that it does *not* fix issues with argument values and non-ZST constants, which emit their own stores that have debug info on them, like #128945).
r? `@michaelwoerister`
make basic allocation functions track_caller in Miri for nicer backtraces This matches what we did with basic pointer and atomic operations.
skip target sanity check when it's a `local-rebuild` Running the stage0 target sanity check on the newly built compiler can result in errors and incorrect assumptions. Resolves #130242
rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 9) Follow up * rust-lang/rust#116214 * rust-lang/rust#116432 * rust-lang/rust#116824 * rust-lang/rust#118105 * rust-lang/rust#119561 * rust-lang/rust#123574 * rust-lang/rust#125382 * rust-lang/rust#127671 As always, it's easier to review the commits one at a time. Don't use the Files Changed tab. It's confusing.
Rollup of 3 pull requests Successful merges: - #130245 (make basic allocation functions track_caller in Miri for nicer backtraces) - #130261 (skip target sanity check when it's a `local-rebuild`) - #130287 (rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 9)) r? `@ghost` `@rustbot` modify labels: rollup
interpret: simplify SIMD type handling This is possible as a follow-up to rust-lang/rust#129403
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 #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 #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 #128848
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]: #120661 [1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models [2]: rust-lang/rust#121289 (comment)
Dataflow cleanups r? `@cjgillot`
Add set_dcx to ParseSess After [this](rust-lang/rust#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.
…mpiler-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.
…onv, 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.
Rollup of 6 pull requests Successful merges: - #129320 (Fix crash when labeling arguments for call_once and friends) - #130266 (target: default to the medium code model on LoongArch targets) - #130297 (Dataflow cleanups) - #130299 (Add set_dcx to ParseSess) - #130301 (some fixes for clashing_extern_declarations lint) - #130305 (Clippy: consider msrv for const context for const_float_bits_conv) r? `@ghost` `@rustbot` modify labels: rollup
…tree, r=albertlarsan68 bootstrap: handle worktrees in warn_old_master_branch fixes #130111
[bootstrap] Add support for building gcc and libgccjit As `@eholk` summarized below: > From my understanding, this change would add libgccjit as an optional component to the Rust distribution. This library is licensed under GPLv2 and currently we do not have any other components under that license so it would be a new license, and one that is generally more restrictive than the other licenses we use. It'll greatly improve the experience for anyone wanting to work on the GCC backend from the compiler. Should help with rust-lang/rust#124172. Will unblock #124353. r? `@Kobzol`
|
@bors r+ |
|
☀️ Test successful - checks-actions |
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.
No description provided.