Conversation
Update to LLVM 21.1.8 Fixes rust-lang/rust#149522.
Remove Expressions (and just use a Vec) in coerce Let's see if this has much of a perf impact - would be nice to clean this up a bit r? ghost
Prefer remapping the relative `library/` and `compiler/` directories This is done to avoid leaking the relative paths to the standard library after the overall of filenames in rust-lang/rust#149709. Noted that the paths were already leaking before, but to a lesser extent since most (but not all) the paths embedded in the distributed `rlib` were absolute. In general Cargo compiles workspace members with relative paths, so it's better anyway to remap the relative path. In addition to our tests I have manually confirmed that it also works as expected for the printed diagnostics paths. cf. https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/remapping.20of.20the.20standard.20library/near/564093571
Perf regression fix The only thing changed from the previous PR is that I removed `output_is_inhabited` from hot path, and hide it behind condition, so now it will compute it less frequent follow up on rust-lang/rust#149664
Better closure requirement propagation. Fixes rust-lang/rust#148289 Fixes rust-lang/rust#104477 Should unblock rust-lang/rust#148187 When propagating closure requirements we: - no longer try to find a post dominiting region for the list of non-local lower bounds of `longer_fr`. - we filter the list of `longer_fr-: shorter_fr+` to only these constraints between external regions which are required regardless. If no such constraint exists, we fall back to propagating all of them. See the [FCP](rust-lang/rust#148329 (comment)) for more information. r? `@lcnr`
Fix trailing newline in JUnit formatter `write_message()` expects messages to contain no newlines. Fixes rust-lang/rust#149436
…,saethlin Replace Rvalue::NullaryOp by a variant in mir::Operand. Based on rust-lang/rust#148151 This PR fully removes the MIR `Rvalue::NullaryOp`. After rust-lang/rust#148151, it was only useful for runtime checks like `ub_checks`, `contract_checks` and `overflow_checks`. These are "runtime" checks, boolean constants that may only be `true` in codegen. It depends on a rustc flag passed to codegen, so we need to represent those flags cross-crate. This PR replaces those runtime checks by special variants in MIR `ConstValue`. This allows code that expects constants to manipulate those as such, even if we may not always be able to evaluate them to actual scalars.
automate offload, part 2 - clang calls This automates steps 2+3 (the clang invocations) of the rust offload usage pipeline. Now all that remains is a clang-linker-invocation after this step. r? oli-obk
Subtree sync for rustc_codegen_cranelift The main highlight this time is a Cranelift update. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler
MGCA: Support struct expressions without intermediary anon consts r? oli-obk tracking issue: rust-lang/rust#132980 Fixes rust-lang/rust#127972 Fixes rust-lang/rust#137888 Fixes rust-lang/rust#140275 due to delaying a bug instead of ICEing in HIR ty lowering. ### High level goal Under `feature(min_generic_const_args)` this PR adds another kind of const argument. A struct/variant construction const arg kind. We represent the values of the fields as themselves being const arguments which allows for uses of generic parameters subject to the existing restrictions present in `min_generic_const_args`: ```rust fn foo<const N: Option<u32>>() {} trait Trait { #[type_const] const ASSOC: usize; } fn bar<T: Trait, const N: u32>() { // the initializer of `_0` is a `N` which is a legal const argument // so this is ok. foo::<{ Some::<u32> { 0: N } }>(); // this is allowed as mgca supports uses of assoc consts in the // type system. ie `<T as Trait>::ASSOC` is a legal const argument foo::<{ Some::<u32> { 0: <T as Trait>::ASSOC } }>(); // this on the other hand is not allowed as `N + 1` is not a legal // const argument foo::<{ Some::<u32> { 0: N + 1 } }>(); } ``` This PR does not support uses of const ctors, e.g. `None`. And also does not support tuple constructors, e.g. `Some(N)`. I believe that it would not be difficult to add support for such functionality after this PR lands so have left it out deliberately. We currently require that all generic parameters on the type being constructed be explicitly specified. I haven't really looked into why that is but it doesn't seem desirable to me as it should be legal to write `Some { ... }` in a const argument inside of a body and have that desugar to `Some::<_> { ... }`. Regardless this can definitely be a follow-up PR and I assume this is some underlying consistency with the way that elided args are handled with type paths elsewhere. This PRs implementation of supporting struct expressions is somewhat incomplete. We don't handle `Foo { ..expr }` at all and aren't handling privacy/stability. The printing of `ConstArgKind::Struct` HIR nodes doesn't really exist either :') I've tried to keep the implementation here somewhat deliberately incomplete as I think a number of these issues are actually quite small and self contained after this PR lands and I'm hoping it could be a good set of issues to mentor newer contributors on 🤔 I just wanted the "bare minimum" required to actually demonstrate that the previous changes are "necessary". ### `ValTree` now recurse through `ty::Const` In order to actually represent struct/variant construction in `ty::Const` without going through an anon const we would need to introduce some new `ConstKind` variant. Let's say some hypothetical `ConstKind::ADT(Ty<'tcx>, List<Const<'tcx>>)`. This variant would represent things the same way that `ValTree` does with the first element representing the `VariantIdx` of the enum (if its an enum), and then followed by a list of field values in definition order. This *could* work but there are a few reasons why it's suboptimal. First it would mean we have a second kind of `Const` that can be normalized. Right now we only have `ConstKind::Unevaluated` which possibly needs normalization. Similarly with `TyKind` we *only* have `TyKind::Alias`. If we introduced `ConstKind::ADT` it would need to be normalized to a `ConstKind::Value` eventually. This feels to me like it has the potential to cause bugs in the long run where only `ConstKind::Unevaluated` is handled by some code paths. Secondly it would make type equality/inference be kind of... weird... It's desirable for `Some { 0: ?x } eq Some { 0: 1_u32 }` to result in `?x=1_u32`. I can't see a way for this to work with this `ConstKind::ADT` design under the current architecture for how we represent types/consts and generally do equality operations. We would need to wholly special case these two variants in type equality and have a custom recursive walker separate from the existing architecture for doing type equality. It would also be somewhat unique in that it's a non-rigid `ty::Const` (it can be normalized more later on in type inference) while also having somewhat "structural" equality behaviour. Lastly, it's worth noting that its not *actually* `ConstKind::ADT` that we want. It's desirable to extend this setup to also support tuples and arrays, or even references if we wind up supporting those in const generics. Therefore this isn't really `ConstKind::ADT` but a more general `ConstKind::ShallowValue` or something to that effect. It represents at least one "layer" of a types value :') Instead of doing this implementation choice we instead change `ValTree::Branch`: ```rust enum ValTree<'tcx> { Leaf(ScalarInt), // Before this PR: Branch(Box<[ValTree<'tcx>]>), // After this PR Branch(Box<[Const<'tcx>]>), } ``` The representation for so called "shallow values" is now the same as the representation for the *entire* full value. The desired inference/type equality behaviour just falls right out of this. We also don't wind up with these shallow values actually being non-rigid. And `ValTree` *already* supports references/tuples/arrays so we can handle those just fine. I think in the future it might be worth considering inlining `ValTree` into `ty::ConstKind`. E.g: ```rust enum ConstKind { Scalar(Ty<'tcx>, ScalarInt), ShallowValue(Ty<'tcx>, List<Const<'tcx>>), Unevaluated(UnevaluatedConst<'tcx>), ... } ``` This would imply that the usage of `ValTree`s in patterns would now be using `ty::Const` but they already kind of are anyway and I think that's probably okay in the long run. It also would mean that the set of things we *could* represent in const patterns is greater which may be desirable in the long run for supporting things such as const patterns of const generic parameters. Regardless, this PR doesn't actually inline `ValTree` into `ty::ConstKind`, it only changes `Branch` to recurse through `Const`. This change could be split out of this PR if desired. I'm not sure if there'll be a perf impact from this change. It's somewhat plausible as now all const pattern values that have nesting will be interning a lot more `Ty`s. We shall see :> ### Forbidding generic parameters under mgca Under mgca we now allow all const arguments to resolve paths to generic parameters. We then *later* actually validate that the const arg should be allowed to access generic parameters if it did wind up resolving to any. This winds up just being a lot simpler to implement than trying to make name resolution "keep track" of whether we're inside of a non-anon-const const arg and then encounter a `const { ... }` indicating we should now stop allowing resolving to generic parameters. It's also somewhat in line with what we'll need for a `feature(generic_const_args)` where we'll want to decide whether an anon const should have any generic parameters based off syntactically whether any generic parameters were used. Though that design is entirely hypothetical at this point :) ### Followup Work - Make HIR ty lowering check whether lowering generic parameters is supported and if not lower to an error type/const. Should make the code cleaner, fix some other bugs, and maybe(?) recover perf since we'll be accessing less queries which I think is part of the perf regression of this PR - Make the ValTree setup less scuffed. We should find a new name for `ConstKind::Value` and the `Val` part of `ValTree` and `ty::Value` as they no longer correspond to a fully normalized structure. It may also be worth looking into inlining `ValTreeKind` into `ConstKind` or atleast into `ty::Value` or sth 🤔 - Support tuple constructors and const constructors not just struct expressions. - Reduce code duplication between HIR ty lowering's handling of struct expressions, and HIR typeck's handling of struct expressions - Try fix perf rust-lang/rust#149114 (comment). Maybe this will clear up once we clean up `ValTree` a bit and stop doing double interning and whatnot
Fix ICE in normalization during closure capture analysis (#149746) This fixes an internal compiler error that occurred when normalizing associated types during closure capture analysis. The Fix: Modified rustc_middle/src/ty/normalize_erasing_regions.rs to gracefully handle projection normalization failures instead of panicking when analyzing closure captures. Regression Test: Added tests/ui/associated-types/normalization-ice-issue-149746.rs, a reproduction case involving complex associated type projections (<() as Owner>::Ty<T>) that previously crashed the compiler. Verified it now emits a standard type error (E0277). Fixes rust-lang/rust#149746
Don't export upstream monomorphizations from compiler-builtins
Tidying up tests/ui/issues 15 tests [6/N] > [!NOTE] > Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge. part of rust-lang/rust#133895 r? Kivooeo
Update bors configuration Updates the configuration of bors to bring it up to speed with homu, in preparation for rust-lang/infra-team#168. Mirrors configuration from homu's [configuration file](https://github.com/rust-lang/homu/blob/master/cfg.production.toml#L46). This PR also enables reporting of merge conflicts, so that we can test this part of bors on `rust-lang/rust`. The merge conflict reports will be duplicated (until/unless we disable it in homu), but that hopefully shouldn't be such a big deal. r? ``@marcoieni``
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to 1127d2a. Created using https://github.com/rust-lang/josh-sync. r? ``@ghost``
use new term in description of --target this changes _triple_ to _tuple_ in `--target` description
Rollup of 6 pull requests Successful merges: - rust-lang/rust#149800 (Fix ICE in normalization during closure capture analysis (rust-lang/rust#149746)) - rust-lang/rust#150182 (Don't export upstream monomorphizations from compiler-builtins) - rust-lang/rust#150216 (Tidying up tests/ui/issues 15 tests [6/N]) - rust-lang/rust#150308 (Update bors configuration) - rust-lang/rust#150314 (rustc-dev-guide subtree update) - rust-lang/rust#150319 (use new term in description of --target) r? `@ghost` `@rustbot` modify labels: rollup
Remap both absolute and relative paths when building `rustc` and `std` Turns out [#150110](rust-lang/rust#150110) didn't work as expected, because when the standard library sources are present, we [helpfully un-remap the paths](https://github.com/rust-lang/rust/blob/e951f470d76febcc6f0a5b409c509eb77450a336/compiler/rustc_metadata/src/rmeta/decoder.rs#L1656-L1702) to the local directory of the user, including when we are building the compiler and standard library it-self (duh!), and since those paths are absolute (not relative), our purely relative remapping didn't pick them up. This behavior wasn't a issue before because the un-remap logic immediately tries to remap them again, and since we had the absolute remapping we would just remap them to the the same thing. To fix that issue I've adjusted our remapping to remap both the absolute and relative paths when building `rustc` and `std`, as well as added a run-make to make sure we don't regress it again (with a new `needs-std-remap-debuginfo` directive). r? `@jieyouxu`
stabilize `lazy_get` closes rust-lang/rust#129333 FCP is finished in rust-lang/rust#129333 (comment) ```@rustbot``` modify labels: +T-libs-api
Correct terminology in Clone I think the current wording around Clone here is confusing: - "Rust does not allow you to reimplement `Copy`" - reimplement isn't a piece of Rust terminology, but as written it sounds like you can't write `impl Copy for X`, which you can. - "you may reimplement `Clone`" - again reimplement isn't really a thing that you do to a trait, the distinction is between manually implementing and deriving. - "you can automatically make anything `Copy` be `Clone` as well" - you don't have a choice about it, so it doesn't really make sense to say you "can ... make" this happen.
mir_build: Classify `TestableCase::Constant` into multiple sub-kinds In match lowering, when choosing a test for a `TestableCase::Constant`, there is some ad-hoc logic for inspecting the pattern type and deciding what kind of test is suitable. There is also some very similar logic later, when partitioning cases into buckets based on the chosen test. Instead of having that ad-hoc logic in multiple places, I think it's better to perform an up-front classification when lowering `thir::PatKind::Constant` to `TestableCase::Constant`, and then have the later steps simply match on an enum variant. There should be no change to the resulting built MIR. (I will note that the logic/invariants involved are a bit unclear, so there is a risk of accidental minor differences.)
Rollup of 3 pull requests Successful merges: - rust-lang/rust#150016 (stabilize `lazy_get`) - rust-lang/rust#150139 (Correct terminology in Clone) - rust-lang/rust#150238 (mir_build: Classify `TestableCase::Constant` into multiple sub-kinds) r? `@ghost` `@rustbot` modify labels: rollup
stdarch subtree update Subtree update of `stdarch` to rust-lang/stdarch@6111906. Created using https://github.com/rust-lang/josh-sync. r? `@sayantn` My first josh sync, it lgtm, but let me know if I missed something. I'm especially looking forward to the amd GPU module, which we want to use for the offload project.
…e-numbers, r=yotamofek Fix copy code example with line numbers Fixes rust-lang/rust#150339. Since the line numbers are now included in the actual highlighted code, we need to filter them out when we "copy" the code. r? `@yotamofek`
JumpThreading: compute place and value indices on-demand Profiling JumpThreading reveals that a large part of the runtime happens constructing the place and value `Map`. This is unfortunate, as jump-threading may end up not even doing anything. The cause for this large up-front cost is following: `Map` attempts to create a `PlaceIndex` for each place that *may* hold a relevant value. This means all places that appear in MIR, but also all places whose value is accessed by a projection of a copy of a larger place. This PR refactors the creation of `Map` to happen on-demand: place and value indices are created when threading computation happens. The up-front mode is still relevant for DataflowConstProp, so is not touched.
…Simulacrum Add `MaybeDangling` to `core` This is the library part of adding `MaybeDangling`. Note that it doesn't actually do anything described in its docs (yet), I'll make a separate PR for that. Tracking issue: rust-lang/rust#118166. r? libs cc `@RalfJung`
Update cargo submodule 17 commits in e91b2baa632c0c7e84216c91ecfe107c37d887c1..94c368ad2b9db0f0da5bdd8421cea13786ce4412 2025-12-13 16:29:21 +0000 to 2025-12-26 19:39:15 +0000 - fix(vendor): unpack from local-registry cache path (rust-lang/cargo#16435) - feat(index): Stabilize pubtime (rust-lang/cargo#16372) - Experiment: Render timing pipeline in SVG (rust-lang/cargo#15091) - chore(triagebot): auto-label `Command-report` (rust-lang/cargo#16429) - fix(sbom): Don't set CARGO_SBOM_PATH when empty (like stable) (rust-lang/cargo#16419) - chore(ci): report-timings to upload HTML report (rust-lang/cargo#16416) - fix(report): get the same feature parity of `--timings` (rust-lang/cargo#16414) - fix(docs): Document the only possible values for DEBUG in build scripts (rust-lang/cargo#16413) - fix(log): emit fingeprint log also for no-rebuild unit (rust-lang/cargo#16408) - Fix link to `doc_cfg` docs in cargo book (rust-lang/cargo#16404) - Add best pratice for how to check in generated files (rust-lang/cargo#16405) - test: Use a larger default term width (rust-lang/cargo#16403) - Document more services and permissions of the cargo team (rust-lang/cargo#16402) - fix(new): Improve quality of package name error messages (rust-lang/cargo#16398) - feat(log): add more log events (rust-lang/cargo#16390) - chore: bump to 0.95.0; update changelog (rust-lang/cargo#16395) - Cache submodule into git db (rust-lang/cargo#16246) r? ghost
…index, r=Mark-Simulacrum Fix `LinkedList::CursorMut::pop_front` to correctly update index When `pop_front` was called while the cursor pointed to the front element, `move_next` incremented the index but it was never decremented afterwards, causing the index to incorrectly report 1 instead of 0. Always decrement the index after popping from front using `saturating_sub` to handle edge cases safely. Fixes rust-lang/rust#147616
added 2 commits
December 29, 2025 04:27
This updates the rust-version file to 7fefa09b90ca57b8a0e0e4717d672d38a0ae58b5.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 7fefa09b90ca57b8a0e0e4717d672d38a0ae58b5 Filtered ref: 002cd53 Upstream diff: rust-lang/rust@2dc3024...7fefa09 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
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.