about summary refs log tree commit diff
path: root/compiler
AgeCommit message (Collapse)AuthorLines
2025-07-31Auto merge of #144723 - Zalathar:rollup-f9e0rfo, r=Zalatharbors-143/+145
Rollup of 3 pull requests Successful merges: - rust-lang/rust#144657 (fix: Only "close the window" when its the last annotated file) - rust-lang/rust#144665 (Re-block SRoA on SIMD types) - rust-lang/rust#144713 (`rustc_middle::ty` cleanups) r? `@ghost` `@rustbot` modify labels: rollup
2025-07-31Rollup merge of #144713 - nnethercote:rustc_middle-ty-cleanups, r=lcnrStuart Cook-140/+135
`rustc_middle::ty` cleanups r? `@davidtwco`
2025-07-31Rollup merge of #144665 - scottmcm:restore-sroa-simd-check, r=compiler-errorsStuart Cook-1/+5
Re-block SRoA on SIMD types Fixes rust-lang/rust#144621
2025-07-31Rollup merge of #144657 - Muscraft:fix-unicode-close-window, r=fee1-deadStuart Cook-2/+5
fix: Only "close the window" when its the last annotated file While comparing the Unicode theme output of `rustc` and `annotate-snippets`, I found that `rustc` would ["close the window"](https://github.com/rust-lang/rust/blob/686bc1c5f9c06762b18082434c04d514acf6707e/compiler/rustc_errors/src/emitter.rs#L1025-L1027) (draw a `╰╴`), even though there were other annotated files that followed the current one. This PR makes it so the emitter will only "close the window" on the last annotated file. Before: ``` error[E0624]: method `method` is private ╭▸ $DIR/close_window.rs:9:7 │ LL │ s.method(); ╰╴ ━━━━━━ private method │ ⸬ $DIR/auxiliary/close_window.rs:3:5 │ LL │ fn method(&self) {} ╰╴ ──────────────── private method defined here ``` After: ``` error[E0624]: method `method` is private ╭▸ $DIR/close_window.rs:9:7 │ LL │ s.method(); │ ━━━━━━ private method │ ⸬ $DIR/auxiliary/close_window.rs:3:5 │ LL │ fn method(&self) {} ╰╴ ──────────────── private method defined here ```
2025-07-31Fix linker-plugin-lto only doing thin ltoFlakebi-1/+3
When rust provides LLVM bitcode files to lld and the bitcode contains function summaries as used for thin lto, lld defaults to using thin lto. This prevents some optimizations that are only applied for fat lto. We solve this by not creating function summaries when fat lto is enabled. The bitcode for the module is just directly written out. An alternative solution would be to set the `ThinLTO=0` module flag to signal lld to do fat lto. The code in clang that sets this flag is here: https://github.com/llvm/llvm-project/blob/560149b5e3c891c64899e9912e29467a69dc3a4c/clang/lib/CodeGen/BackendUtil.cpp#L1150 The code in LLVM that queries the flag and defaults to thin lto if not set is here: https://github.com/llvm/llvm-project/blob/e258bca9505f35e0a22cb213a305eea9b76d11ea/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp#L4441-L4446
2025-07-31fix: Only "close the window" when its the last annotated fileScott Schafer-2/+5
2025-07-31Extend `is_case_difference` to handle digit-letter confusablesxizheyin-35/+111
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-07-31Rollup merge of #144717 - nnethercote:mv-rustc_middle-parameterized, ↵Stuart Cook-189/+170
r=compiler-errors Move `rustc_middle::parameterized` It doesn't need to be in `rustc_middle`. r? `@compiler-errors`
2025-07-31Rollup merge of #144685 - jdonszelmann:lang-items-once, r=wafflelapkinStuart Cook-5/+3
Only extract lang items once in codegen_fn_attrs This one should be obvious. These two extraction points used to be far apart but now that they're refactored to be close it was rather obvious we're just doing double work.... r? ``@WaffleLapkin`` Buils on rust-lang/rust#144655
2025-07-31Rollup merge of #144663 - Zalathar:empty-span, r=petrochenkovStuart Cook-26/+40
coverage: Re-land "Enlarge empty spans during MIR instrumentation" This allows us to assume that coverage spans will only be discarded during codegen in very unusual situations. --- This seemingly-simple change has a rather messy history: - rust-lang/rust#140847 - rust-lang/rust#141650 - rust-lang/rust#144298 - rust-lang/rust#144480 Since then, a number of related changes have landed that should make it reasonable to try again: - rust-lang/rust#144530 - rust-lang/rust#144560 - rust-lang/rust#144616 In particular, we have multiple fixes/mitigations, and a confirmed regression test for the original bug that is not triggered by re-landing the changes in this PR.
2025-07-31Rollup merge of #144232 - xacrimon:explicit-tail-call, r=WaffleLapkinStuart Cook-12/+156
Implement support for `become` and explicit tail call codegen for the LLVM backend This PR implements codegen of explicit tail calls via `become` in `rustc_codegen_ssa` and support within the LLVM backend. Completes a task on (https://github.com/rust-lang/rust/issues/112788). This PR implements all the necessary bits to make explicit tail calls usable, other backends have received stubs for now and will ICE if you use `become` on them. I suspect there is some bikeshedding to be done on how we should go about implementing this for other backends, but it should be relatively straightforward for GCC after this is merged. During development I also put together a POC bytecode VM based on tail call dispatch to test these changes out and analyze the codegen to make sure it generates expected assembly. That is available [here](https://github.com/xacrimon/tcvm).
2025-07-31Rollup merge of #143672 - beepster4096:box_drop_flags_again, r=oli-obkStuart Cook-26/+28
Fix Box allocator drop elaboration New version of rust-lang/rust#131146. Clearing Box's drop flag after running its destructor can cause it to skip dropping its allocator, so just don't. Its cleared by the drop ladder code afterwards already. Unlike the last PR this also handles other types with destructors properly, in the event that we can have open drops on them in the future (by partial initialization or DerefMove or something). Finally, I also added tests for the interaction with async drop here but I discovered rust-lang/rust#143658, so one of the tests has a `knownbug` annotation. Not sure if it should be in this PR at all though. Fixes rust-lang/rust#131082 r? wesleywiser - prev. reviewer
2025-07-31Fix up size asserts.Nicholas Nethercote-14/+26
- Put them in the module that defines the type. - Add some `WithCachedTypeInfo<T>` asserts for consistency.
2025-07-31Move `InferVarInfo` out of `rustc_middle`.Nicholas Nethercote-15/+16
It's only used in `rustc_hir_typeck`.
2025-07-31Remove `TyCtxt::get_attrs_unchecked`.Nicholas Nethercote-10/+2
It's identical to `TyCtxt::get_all_attrs` except it takes `DefId` instead of `impl Into<DefIf>`.
2025-07-31Remove `ParamEnvAnd::into_parts`.Nicholas Nethercote-14/+8
The fields are public, so this doesn't need a method, normal deconstruction and/or field access is good enough.
2025-07-31Move `TermVid` out of `rustc_middle`.Nicholas Nethercote-28/+26
It's only used in `rustc_infer`.
2025-07-31Move `rustc_middle::parameterized` to `rustc_metadata`.Nicholas Nethercote-176/+170
It's only used there.
2025-07-31Remove unused `ParameterizedOverTcx` impls.Nicholas Nethercote-13/+0
2025-07-31Consider operator's span when computing binop expr spanMichael Goulet-6/+9
2025-07-31Move `ParamTerm` out of `rustc_middle`.Nicholas Nethercote-20/+20
It's only used in `rustc_hir_typeck`.
2025-07-31Move an `EarlyParamRegion` impl block.Nicholas Nethercote-9/+9
Next to all the other `EarlyParamRegion` pieces.
2025-07-31Move `ImplHeader` out of `rustc_middle`.Nicholas Nethercote-18/+19
It's not used in `rustc_middle`, and `rustc_trait_selection` is a better place for it.
2025-07-31Move `ResolverOutputs` out of `rustc_middle`.Nicholas Nethercote-9/+9
It's not used in `rustc_middle`, and `rustc_resolve` is a better place for it.
2025-07-31Remove unused `impl_decodable_via_ref!` entries.Nicholas Nethercote-3/+0
2025-07-31Auto merge of #144405 - lcnr:hir-typeck-uniquify, r=BoxyUwUbors-45/+228
uniquify root goals during HIR typeck We need to rely on region identity to deal with hangs such as https://github.com/rust-lang/trait-system-refactor-initiative/issues/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 https://github.com/rust-lang/trait-system-refactor-initiative/issues/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 https://github.com/rust-lang/rust/pull/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 https://github.com/rust-lang/trait-system-refactor-initiative/issues/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`
2025-07-31Use specific name for "frame" span fieldStypox-1/+1
Otherwise the field would be named "message" by default
2025-07-31Use new enter_trace_span! syntax for layout_of & friendsStypox-3/+3
2025-07-31Uniform enter_trace_span! and add documentationStypox-4/+63
The macro was uniformed between rustc_const_eval and miri
2025-07-30Auto merge of #116316 - cjgillot:incr-privacy, r=petrochenkovbors-1/+0
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 https://github.com/rust-lang/rust/pull/116316#issuecomment-3094672105 shows that we manage it. The cost is extra dep-graph bookkeeping.
2025-07-30stall ConstArgHasType in compute_goal_fast_pathMichael Goulet-0/+7
2025-07-30Rollup merge of #144675 - jieyouxu:compiletest-staging, r=KobzolSamuel Tardieu-4/+6
Reject running `compiletest` self-tests against stage 0 rustc unless explicitly allowed Currently, in `pr-check-1`, we run `python3 ../x.py test --stage 0 src/tools/compiletest`, which is `compiletest` self-tests against stage 0 rustc. This makes it very annoying for PRs wanting to change target spec JSON format, which `compiletest` depends on for target information, as otherwise `compiletest` would have to know how to handle 2 different target spec JSON formats and know when to pick which. Instead of doing that, we change `compiletest` self-tests to reject running against stage 0 `rustc` *unless* explicitly allowed with `build.compiletest-allow-stage0=true`. `build.compiletest-allow-stage0` is a proper bootstrap config option in favor of the ad-hoc `COMPILETEST_FORCE_STAGE0` env var. This means that: - `./x test src/tools/compiletest --stage=0` is not allowed, unless `build.compiletest-allow-stage0=true` is set. In this scenario, `compiletest` self-tests should be expected to fail unless the stage 0 `rustc` as provided is like codegen_cranelift where it's *actually* built from in-tree `rustc` sources. - In CI, we change `./x test src/tools/compiletest --stage=0` to `./x test src/tools/compiletest --stage=1`, and move it to `pr-check-2`. Yes, this involves building the stage 1 compiler, but `pr-check-2` already has to build stage 1 compiler to test stage 1 library crates. - Crucially, this means that **`compiletest` is only intended to support one target spec JSON format**, namely the one corresponding to the in-tree `rustc`. - This should preserve the `compiletest-use-stage0-libtest` UX optimization where changing `compiler/` tree should still not require rebuilding `compiletest` as long as `build.compiletest-use-stage0-libtest=true`, as that should remain orthogonal. This is completely unlike my previous attempt at https://github.com/rust-lang/rust/pull/144563 that tries to do a way more invasive change which would cause the rebuild problem. Best reviewed commit-by-commit. --- r? `@Kobzol`
2025-07-30Rollup merge of #144655 - jdonszelmann:cleanup-codegen-fn-attrs, r=WaffleLapkinSamuel Tardieu-237/+289
clean up codegen fn attrs This honestly had become a mess over time and needed some love. No behavior should've changed, and I effectively just moved code around. Though, I can't promise there weren't any bugs in the original code with how randomly it was organised..... r? `@WaffleLapkin`
2025-07-30Rollup merge of #143465 - kornelski:extern-name, r=petrochenkovSamuel Tardieu-6/+56
Support multiple crate versions in --extern-html-root-url Rustdoc's `--extern-html-root-url` used to use `tcx.crate_name()` to identify crates, but that used crates' internal names from their metadata, instead of names given to them in `--extern`. That was confusing, because both `--extern…` arguments seem related and use similar syntax. Crucially, this didn't work correctly with Cargo's package aliases or multiple versions of crates. `sess.opts.externs` lacks `CrateNum`, and `Resolver.extern_prelude` gets destroyed before `rustdoc` has a chance to see it, so I've had to save this mapping in `CStore`. Just in case, I've kept the previous mapping by crate name as a fallback for crates that weren't matched by their extern name. Fixes rust-lang/rust#76296
2025-07-30only extract lang items onceJana Dönszelmann-5/+3
2025-07-30clean up codegen fn attrsJana Dönszelmann-237/+289
2025-07-30extend commentlcnr-0/+13
2025-07-30add comment and opaque type fixmelcnr-0/+11
2025-07-30handle region dependent goals due to infer varslcnr-19/+76
2025-07-30Update `codegen_{cranelift,gcc}` and `opt-dist` to use ↵Jieyou Xu-4/+6
`build.compiletest-allow-stage0`
2025-07-30Rollup merge of #144666 - compiler-errors:correct-late, r=lqdStuart Cook-6/+21
Make sure to account for the right item universal regions in borrowck Fixes https://github.com/rust-lang/rust/issues/144608. The ICE comes from a mismatch between the liberated late bound regions (i.e. "`ReLateParam`"s) that come from promoting closure outlives, and the regions we have in our region vid mapping from `UniversalRegions`. When building `UniversalRegions`, we end up using the liberated regions from the binder of the closure's signature: https://github.com/rust-lang/rust/blob/c8bb4e8a126cf38cff70cea488a3a423a5321954/compiler/rustc_borrowck/src/universal_regions.rs#L521 Notably, this signature may be anonymized if the closure signature being deduced comes from an external constraints: https://github.com/rust-lang/rust/blob/c8bb4e8a126cf38cff70cea488a3a423a5321954/compiler/rustc_hir_typeck/src/closure.rs#L759-L762 This is true in the test file I committed, where the signature is influenced by the `impl FnMut(&mut ())` RPIT. However, when promoting a type outlives constraint we end up creating a late bound lifetime mapping that disagrees with those liberated late bound regions we constructed in `UniversalRegions`: https://github.com/rust-lang/rust/blob/c8bb4e8a126cf38cff70cea488a3a423a5321954/compiler/rustc_borrowck/src/universal_regions.rs#L299 Specifically, in `for_each_late_bound_region_in_item` (which is called by `for_each_late_bound_region_in_recursive_scope`), we were using `tcx.late_bound_vars` which uses the late bound regions *from the HIR*. This query both undercounts the late bound regions (e.g. those that end up being deduced from bounds), and also doesn't account for the fact that we anonymize them in the signature as mentioned above. https://github.com/rust-lang/rust/blob/c8bb4e8a126cf38cff70cea488a3a423a5321954/compiler/rustc_borrowck/src/universal_regions.rs#L977 This PR fixes that function to use the *correct signature*, which properly considers the bound vars that come from deducing the signature of the closure, and which comes from the closure's args from the `type_of` query.
2025-07-30Rollup merge of #144268 - xizheyin:find-oldest-ancestor, r=jieyouxuStuart Cook-42/+58
Add method `find_ancestor_not_from_macro` and `find_ancestor_not_from_extern_macro` to supersede `find_oldest_ancestor_in_same_ctxt` As I was using it, I realized that the function is supposed to walk up to expand the chain? This seems to be the opposite of what I understood. r? `@jieyouxu`
2025-07-30Make sure to account for the right item universal regions in borrowckMichael Goulet-6/+21
2025-07-29Re-block SRoA on SIMD typesScott McMurray-1/+5
Fixes 144621
2025-07-30coverage: Re-land "Enlarge empty spans during MIR instrumentation"Zalathar-26/+40
This allows us to assume that coverage spans will only be discarded during codegen in very unusual situations.
2025-07-30Auto merge of #144577 - oli-obk:wrapping-niche, r=scottmcmbors-27/+74
Pick the largest niche even if the largest niche is wrapped around fixes rust-lang/rust#144388 r? `@scottmcm`
2025-07-29Rollup merge of #144640 - FractalFir:m68k_arch, r=UrgauJacob Pratt-0/+1
Add support for the m68k architecture in 'object_architecture' This is a tiny PR that adds the m68k architecture to `object_architecture`. This allows us to build rmeta files for that ISA(we use the object crate to pack metadata into object files).
2025-07-29Rollup merge of #144605 - LorrensP-2158466:cache-extern-prelude, r=petrochenkovJacob Pratt-12/+11
Resolve: cachify `ExternPreludeEntry.binding` through a `Cell` Provides interior mutability to the `binding` field of `ExternPreludeEntry` as this field behaves like a cache. Per [zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Parallel.20Macro.20Expansion/near/531390914). A little preparatory work for batched import resolution, which is part of [#gsoc > Project: Parallel Macro Expansion](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Parallel.20Macro.20Expansion). r? `@petrochenkov`
2025-07-29Auto merge of #144557 - cjgillot:lower-more-span, r=compiler-errorsbors-16/+45
Complete span AST lowering. r? `@ghost`
2025-07-29Reuse `sign_extend` helperOli Scherer-3/+3