Rustc pull update #1889
Merged
Rustc pull update #1889
Conversation
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Ports `#[macro_use]` and `#[macro_escape]` to the new attribute parsing infrastructure Ports `#[macro_use]` and `#[macro_escape]` to the new attribute parsing infrastructure for rust-lang/rust#131229 (comment) r? `@jdonszelmann` `@oli-obk`
Consider parent predicates in ImpossiblePredicates pass. This pass is double edged. It avoids some ICEs (yay!) but also degrades diagnostics from constant evaluation. Fixes rust-lang/rust#121363 Fixes rust-lang/rust#131507 Fixes rust-lang/rust#140100 Fixes rust-lang/rust#140365
Enforce that PR CI jobs are a subset of Auto CI jobs modulo carve-outs ### Background Currently, it is possible for a PR with red PR-only CI to pass Auto CI, then all subsequent PR CI runs will be red until that is fixed, even in completely unrelated PRs. For instance, this happened with PR-CI-only Spellcheck (rust-lang/rust#144183). See more discussions at [#t-infra > Spellcheck workflow now fails on all PRs (tree bad?)](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Spellcheck.20workflow.20now.20fails.20on.20all.20PRs.20.28tree.20bad.3F.29/with/529769404). ### CI invariant: PR CI jobs are a subset of Auto CI jobs modulo carve-outs To prevent red PR CI in completely unrelated subsequent PRs and PR CI runs, we need to maintain an invariant that **PR CI jobs are a subset of Auto CI jobs modulo carve-outs**. This is **not** a "strict" subset relationship: some jobs necessarily have to differ under PR CI and Auto CI environments, at least in the current setup. Still, we can try to enforce a weaker "subset modulo carve-outs" relationship between CI jobs and their corresponding Auto jobs. For instance: - `x86_64-gnu-tools` will have `auto`-only env vars like `DEPLOY_TOOLSTATES_JSON: toolstates-linux.json`. - `tidy` will want to `continue_on_error: true` in PR CI to allow for more "useful" compilation errors to also be reported, whereas it should be `continue_on_error: false` in Auto CI to prevent wasting Auto CI resources. The **carve-outs** are: 1. `env` variables. 2. `continue_on_error`. We enforce this invariant through `citool`, so only affects job definitions that are handled by `citool`. Notably, this is not sufficient *alone* to address the CI-only Spellcheck issue (rust-lang/rust#144183). To carry out this enforcement, we modify `citool` to auto-register PR jobs as Auto jobs with `continue_on_error` overridden to `false` **unless** there's an overriding Auto job for the PR job of the same name that only differs by the permitted **carve-outs**. ### Addressing the Spellcheck PR-only CI issue Note that Spellcheck currently does not go through `citool` or `bootstrap`, and is its own GitHub Actions workflow. To actually address the PR-CI-only Spellcheck issue (rust-lang/rust#144183), and carry out the subset-modulo-carve-outs enforcement universally, this PR additionally **removes the current Spellcheck implementation** (a separate GitHub Actions Workflow). That is incompatible with Homu unless we do some hacks in the main CI workflow. This effectively partially reverts rust-lang/rust#134006 (the separate workflow part, not the tidy extra checks component), but is not prejudice against relanding the `typos`-based spellcheck in another implementation that goes through the usual bootstrap CI workflow so that it does work with Homu. The `typos`-based spellcheck seems to have a good false-positive rate. Closes rust-lang/rust#144183. --- r? infra-ci
Various refactors to the LTO handling code (part 2) Continuing from rust-lang/rust#143388 this removes a bit of dead code and moves the LTO symbol export calculation from individual backends to cg_ssa.
MIR-build: No longer emit assumes in enum-as casting This just uses the `valid_range` from the backend, so it's duplicating the range metadata that now we include on parameters and loads, and thus no longer seems to be useful -- notably there's no codegen test failures from removing it. (Because it's using data from the same source as the backend annotations, it doesn't do anything to mitigate things like rust-lang/rust#144388 where the range in the layout is more permissive than the actual possible discriminants. A variant of this that actually checked the discriminants more specifically might be useful, so could potentially be added in future, but I don't think the *current* checks are actually providing value.) r? mir Randomly turns out that this Fixes rust-lang/rust#121097
Skip walking into param-env component if it has no placeholder/re-var Although it only provides a minor perf improvement, it seems like it could matter in more pathological cases.
Let `codegen_transmute_operand` just handle everything When combined with rust-lang/rust#143720, this means `rvalue_creates_operand` can just return `true` for *every* `Rvalue`. (A future PR could consider removing it, though just letting it optimize out is fine for now.) It's nicer anyway, IMHO, because it avoids needing the layout checks to be consistent in the two places, and thus is an overall reduction in code. Plus it's a more helpful building block when used in other places this way. (TBH, it probably would have been better to have it this way the whole time, but I clearly didn't understand `rvalue_creates_operand` when I originally wrote rust-lang/rust#109843.)
No longer need `alloca`s for consuming `Result<!, i32>` and similar In optimized builds GVN gets rid of these already, but in `opt-level=0` we actually make `alloca`s for this, which particularly impacts `?`-style things that use actually-only-one-variant types like this. While doing so, rewrite `LocalAnalyzer::process_place` to be non-recursive, solving a 6+ year old FIXME. r? codegen
…ler-errors Avoid unnecessary `new_adt`/`new_fn_def` calls. They can be skipped if there are no arguments, avoiding the "relate" operation work and also the subsequent interning. r? `@ghost`
…rrors Preintern some `TyKind::Bound` values The new trait solver produces a lot of these. r? `@compiler-errors`
Don't special-case llvm.* as nounwind Certain LLVM intrinsics, such as `llvm.wasm.throw`, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out `catch_unwind` under inlining or when `llvm.wasm.throw` is used directly by user code. The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as `extern "C"` or other non-unwinding ABIs, so we won't codegen `invoke` for them anyway. Closes rust-lang/rust#132416. `@rustbot` label +T-compiler +A-panic
Rollup of 6 pull requests Successful merges: - rust-lang/rust#143607 (Port the proc macro attributes to the new attribute parsing infrastructure) - rust-lang/rust#144471 (Remove `compiler-builtins-{no-asm,mangled-names}`) - rust-lang/rust#144495 (bump cargo_metadata) - rust-lang/rust#144523 (rustdoc: save target modifiers) - rust-lang/rust#144534 (check_static_item: explain should_check_for_sync choices) - rust-lang/rust#144535 (miri: for ABI mismatch errors, say which argument is the problem) Failed merges: - rust-lang/rust#144536 (miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup
|
r? @folkertdev rustbot has assigned @folkertdev. Use |
Some `let chains` clean-up Not sure if this kind of clean-up is welcoming because of size, but I decided to try out one r? compiler
Allow more MIR SROA This removes some guards on SROA that are no longer needed: - With rust-lang/compiler-team#838 it no longer needs to check for SIMD - With rust-lang/compiler-team#807 it no longer needs to check for niches - This means that `Wrapper(char)` and `Pin<&mut T>` can get SRoA'd now, where previously they weren't because the check was banning SRaA for anything with a niche -- not just things with `#[rustc_layout_scalar_valid_range_*]`. - Technically rust-lang/rust#133652 isn't complete yet, but `NonZero` and `NonNull` have already moved over, so this is fine. At worst this will mean that LLVM gets less `!range` metadata on something that wasn't already fixed by rust-lang/rust#133651 or rust-lang/rust#135236, but that's still sound, and unblocking general SRoA is worth that tradeoff.
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
r? dep-bumps
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 3 packages to latest compatible versions
Updating ipc-channel v0.20.0 -> v0.20.1
Updating rand v0.9.1 -> v0.9.2
Updating redox_syscall v0.5.13 -> v0.5.16
note: pass `--verbose` to see 37 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating rand v0.9.1 -> v0.9.2
note: pass `--verbose` to see 2 unchanged dependencies behind latest
rustbook dependencies:
Locking 1 package to latest compatible version
Updating redox_syscall v0.5.13 -> v0.5.16
```
|
This PR will have to be closed and reopened for CI to run. Will fix that shortly! |
Complete span AST lowering. r? `@ghost`
LoongArch64 LSX fast-path for `str.contains(&str)` Benchmark results with LLVM 21 on LA664: ``` OLD: test bench_is_contained_in ... bench: 43.63 ns/iter (+/- 0.04) NEW: test bench_is_contained_in ... bench: 12.81 ns/iter (+/- 0.01) ```
Free disk space on Windows 2025 runners I've managed to reduce the time deletion takes by: - Using powershell, which is generally faster for filesystem operations than msys2 - Performing deletions concurrently then waiting for them all to complete It still takes 2-10 mins but that's not too bad.
Remove eval_always from check_private_in_public. This PR attempts to avoid re-computing `check_private_in_public` query. First by marking the query as non-`eval_always`, and by reducing the amount of accesses to HIR as much as possible. Latest perf rust-lang/rust#116316 (comment) shows that we manage it. The cost is extra dep-graph bookkeeping.
uniquify root goals during HIR typeck We need to rely on region identity to deal with hangs such as rust-lang/trait-system-refactor-initiative#210 and to keep the current behavior of `fn try_merge_responses`. This is a problem as borrowck starts by replacing each *occurrence* of a region with a unique inference variable. This frequently splits a single region during HIR typeck into multiple distinct regions. As we assume goals to always succeed during borrowck, relying on two occurances of a region being identical during HIR typeck causes ICE. See the now fixed examples in rust-lang/trait-system-refactor-initiative#27 and rust-lang/rust#139409. We've previously tried to avoid this issue by always *uniquifying* regions when canonicalizing goals. This prevents caching subtrees during canonicalization which resulted in hangs for very large types. People rely on such types in practice, which caused us to revert our attempt to reinstate `#[type_length_limit]` in rust-lang/rust#127670. The complete list of changes here: - rust-lang/rust#107981 - rust-lang/rust#110180 - rust-lang/rust#114117 - rust-lang/rust#130821 After more consideration, all occurrences of such large types need to happen outside of typeck/borrowck. We know this as we already walk over all types in the MIR body when replacing their regions with nll vars. This PR therefore enables us to rely on region identity inside of the trait solver by exclusively **uniquifying root goals during HIR typeck**. These are the only goals we assume to hold during borrowck. This is insufficient as type inference variables may "hide" regions we later uniquify. Because of this, we now stash proven goals which depend on inference variables in HIR typeck and reprove them after writeback. This closes rust-lang/trait-system-refactor-initiative#127. This was originally part of rust-lang/rust#144258 but I've moved it into a separate PR. While I believe we need to rely on region identity to fix the performance issues in some way, I don't know whether rust-lang/rust#144258 is the best approach to actually do so. Regardless of how we deal with the hangs however, this change is necessary and desirable regardless. r? `@compiler-errors` or `@BoxyUwU`
This updates the rust-version file to 32e7a4b92b109c24e9822c862a7c74436b50e564.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 32e7a4b92b109c24e9822c862a7c74436b50e564 Filtered ref: 56d8aa1 This merge was created using https://github.com/rust-lang/josh-sync.
github-actions
bot
force-pushed
the
rustc-pull
branch
from
ecb3be6 to
8bdae7f
Compare
Did that happen? It doesn't look like full CI ran here? |
|
This PR was still created using the old CI account. It needs to be closed and reopened after every push for CI to run. Future PRs should be fine. |
|
ok let's try that then |
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.
Latest update from rustc.