about summary refs log tree commit diff
path: root/tests/ui
AgeCommit message (Collapse)AuthorLines
2025-04-16Rollup merge of #139886 - nnethercote:graphviz_borrowck, r=compiler-errorsMatthias Krüger-9/+0
`borrowck_graphviz_*` attribute tweaks A couple of small fixes to out-of-date things. r? ```@davidtwco```
2025-04-16Rollup merge of #139880 - compiler-errors:rpitit-nameless, r=nnethercoteMatthias Krüger-0/+21
Don't compute name of associated item if it's an RPITIT Use `Option::then` in favor of `Option::then_some` to not compute `AssocItem::name` if it fails the condition. Alternatively, I'd be open to changing this just to an `if`. Fixes https://github.com/rust-lang/rust/issues/139873 r? ```@nnethercote```
2025-04-16Rollup merge of #139871 - GuillaumeGomez:async-gen-move, r=compiler-errorsMatthias Krüger-0/+117
Fix wrong "move keyword" suggestion for async gen block Fixes #139839. It was just missing a string comparison with `async gen`.
2025-04-16Remove old diagnostic notes for type ascription syntaxZalathar-43/+0
Type ascription syntax was removed in 2023.
2025-04-16Explicitly annotate edition for `unpretty=expanded` and `unpretty=hir` testsLukas Wirth-7/+53
These emit prelude imports which means they are always edition dependent
2025-04-16stepping into impls for norm is unproductivelcnr-0/+188
2025-04-16Auto merge of #136926 - wesleywiser:stabilize_dwarf-version, r=petrochenkovbors-10/+10
Stabilize `-Zdwarf-version` as `-Cdwarf-version` I propose stabilizing `-Zdwarf-version` as `-Cdwarf-version`. This PR adds a new `-Cdwarf-version` flag, leaving the unstable `-Z` flag as is to ease the transition period. The `-Z` flag will be removed in the future. # `-Zdwarf-version` stabilization report ## What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? No RFC/MCP, this flag was added in https://github.com/rust-lang/rust/pull/98350 and was not deemed large enough to require additional process. The tracking issue for this feature is #103057. ## What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. None that has been extensively debated but there are a few questions that could have been chosen differently: 1. What should the flag name be? The current flag name is very specific to DWARF. Other debuginfo formats exist (msvc's CodeView format or https://en.wikipedia.org/wiki/Stabs) so we could have chosen to generalize the flag name (`-{C,Z} debuginfo-version=dwarf-5` for example). While this would extend cleanly to support formats other than DWARF, there are some downsides to this design. Neither CodeView nor Stabs have specification or format versions so it's not clear what values would be supported beyond `dwarf-{2,3,4,5}` or `codeview`. We would also need to take care to ensure the name does not lead users to think they can pick a format other than one supported by the target. For instance, what would `--target x86_64-pc-windows-msvc -Cdebuginfo-version=dwarf-5` do? 2. What is the behavior when flag is used on targets that do not support DWARF? Currently, passing `-{C,Z} dwarf-version` on targets like `*-windows-msvc` does not do anything. It may be preferable to emit a warning alerting the user that the flag has no effect on the target platform. Alternatively, we could emit an error but this could be annoying since it would require the use of target specific RUSTFLAGS to use the flag correctly (and there isn't a way to target "any platform that uses DWARF" using cfgs). 3. Does the precompiled standard library potentially using a different version of DWARF a problem? I don't believe this is an issue as debuggers (and other such tools) already must deal with the possibility that an application uses different DWARF versions across its statically or dynamically linked libraries. ## Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those. No extensions per se, although future DWARF versions could be considered as such. At present, we validate the requested DWARF version is between 2 and 5 (inclusive) so new DWARF versions will not automatically be supported until the validation logic is adjusted. ## Summarize the major parts of the implementation and provide links into the code (or to PRs) - Targets define their preferred or default DWARF version: https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_target/src/spec/mod.rs#L2369 - We use the target default but this can be overriden by `-{C,Z} dwarf-version` https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L738 - The flag is validated https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L1253-L1258 - When debuginfo is generated, we tell LLVM to use the requested value or the target default https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_codegen_llvm/src/debuginfo/mod.rs#L106 ## Summarize existing test coverage of this feature - Test that we actually generate the appropriate DWARF version - https://github.com/rust-lang/rust/blob/master/tests/assembly/dwarf5.rs - https://github.com/rust-lang/rust/blob/master/tests/assembly/dwarf4.rs - Test that LTO with different DWARF versions picks the highest version - https://github.com/rust-lang/rust/blob/master/tests/assembly/dwarf-mixed-versions-lto.rs - Test DWARF versions 2-5 are valid while 0, 1 and 6 report an error - https://github.com/rust-lang/rust/blob/master/tests/ui/debuginfo/dwarf-versions.rs - Ensure LLVM does not report a warning when LTO'ing different DWARF versions together - https://github.com/rust-lang/rust/blob/master/tests/ui/lto/dwarf-mixed-versions-lto.rs ## Has a call-for-testing period been conducted? If so, what feedback was received? No call-for-testing has been conducted but Rust for Linux has been using this flag without issue. ## What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? All reported bugs have been resolved. ## Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization - Initial implementation in https://github.com/rust-lang/rust/pull/98350 by `@pcwalton` - Stop emitting `.debug_pubnames` and `.debug_pubtypes` when using DWARF 5 in https://github.com/rust-lang/rust/pull/117962 by `@weihanglo.` - Refactoring & cleanups (#135739), fix LLVM warning on LTO with different DWARF versions (#136659) and argument validation (#136746) by `@wesleywiser` ## What FIXMEs are still in the code for that feature and why is it ok to leave them there? No FIXMEs related to this feature. ## What static checks are done that are needed to prevent undefined behavior? This feature cannot cause undefined behavior. We ensure the DWARF version is one of the supported values [here](https://github.com/rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L1255-L1257). ## In what way does this feature interact with the reference/specification, and are those edits prepared? No changes to reference/spec, unstable rustc docs are moved to the stable book as part of the stabilization PR. ## Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. ## What other unstable features may be exposed by this feature? `-Zembed-source` requires use of DWARF 5 extensions but has its own feature gate. ## What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.? No support needed for rustdoc, clippy, rust-analyzer, rustfmt or rustup. Cargo could expose this as an option in build profiles but I would expect the decision as to what version should be used would be made for the entire crate graph at build time rather than by individual package authors. cc-rs has support for detecting the presence of `-{C,Z} dwarf-version` in `RUSTFLAGS` and providing the corresponding flag to Clang/gcc (https://github.com/rust-lang/cc-rs/pull/1395). --- Closes #103057
2025-04-16rustc_target: RISC-V: feature addition batch 2Tsukasa OI-0/+10
This commit adds unprivileged ratified extensions that are either dicoverable from the `riscv_hwprobe` syscall of the Linux kernel (as of version 6.14) plus 1 minus 3 extensions. Plus 1: * "B" This is a combination of "Zba", "Zbb" and "Zbs". Note: Although not required by the RISC-V specification, it is convenient to imply "B" from its three members (will be implemented in LLVM 21/22) but this is not yet implemented in Rust due to current implication handling. It still implies three members *from* "B". Minus 2: * "Zcf" (target_arch = "riscv32" only) This is the compression instruction subset corresponding "F". This is implied from RV32 + "C" + "F" but this complex handling is not yet supported by Rust's feature handling. * "Zcd" This is the compression instruction subset corresponding "D". This is implied from "C" + "D" but this complex handling is not yet supported by Rust's feature handling. * "Supm" Unlike regular RISC-V extensions, "Supm" and "Sspm" extensions do not provide any specific architectural features / constraints but requires *some* mechanisms to control pointer masking for the current mode. For instance, reported existence of the "Supm" extension in Linux means that `prctl` system call to control pointer masking is available and there are alternative ways to detect the existence. Notes: * Because this commit adds the "Zca" extension (an integer subset of the "C" extension), the "C" extension is modified to imply "Zca".
2025-04-16Improve `borrowck_graphviz_*` documentation.Nicholas Nethercote-9/+0
In particular, `borrowck_graphviz_preflow` no longer exists.
2025-04-15Fix wrong suggestion for async gen block and add regression ui test for #139839Guillaume Gomez-0/+117
2025-04-15Rollup merge of #139818 - compiler-errors:normalize-tails, r=oli-obkMatthias Krüger-0/+32
Normalize ADT field in `find_tails_for_unsizing` See the comment inline and in the test. TL;DR is that we're getting getting a type from a `type_of` query and then matching on it structurally in codegen, so we're obligated to normalize it. The fact that this wasn't triggered earlier is that all of the types that have `CoerceUnsized` implementations never encounter aliases when peeling the ADT down to their base reference/ptr type. **NOTE**: I also renamed some things and reorganized the function a bit. Fixes #139812 Fixes #74451, which I didn't think was interesting enough to add another test. r? oli-obk
2025-04-15Don't compute name of associated item if it's an RPITITMichael Goulet-0/+21
2025-04-15Add test for issue 125668reddevilmidzy-0/+5
2025-04-15Update tests.Mara Bos-17/+16
2025-04-15Implement `pin!()` using `super let`.Mara Bos-55/+0
2025-04-15Improve diagnostic for E0178 (bad `+` in type)León Orell Valerian Liehr-45/+45
Namely, use a more sensical primary span. Don't pretty-print AST nodes for the diagnostic message. Why: * It's lossy (e.g., it doesn't replicate trailing `+`s in trait objects. * It's prone to leak error nodes (printed as `(/*ERROR*/)`) since the LHS can easily represent recovered code (e.g., `fn(i32?) + T`).
2025-04-15Improve parse errors for lifetimes in type positionLeón Orell Valerian Liehr-35/+172
2025-04-15Auto merge of #139845 - Zalathar:rollup-u5u5y1v, r=Zalatharbors-43/+687
Rollup of 17 pull requests Successful merges: - #138374 (Enable contracts for const functions) - #138380 (ci: add runners for vanilla LLVM 20) - #138393 (Allow const patterns of matches to contain pattern types) - #139517 (std: sys: process: uefi: Use NULL stdin by default) - #139554 (std: add Output::exit_ok) - #139660 (compiletest: Add an experimental new executor to replace libtest) - #139669 (Overhaul `AssocItem`) - #139671 (Proc macro span API redesign: Replace proc_macro::SourceFile by Span::{file, local_file}) - #139750 (std/thread: Use default stack size from menuconfig for NuttX) - #139772 (Remove `hir::Map`) - #139785 (Let CStrings be either 1 or 2 byte aligned.) - #139789 (do not unnecessarily leak auto traits in item bounds) - #139791 (drop global where-bounds before merging candidates) - #139798 (normalize: prefer `ParamEnv` over `AliasBound` candidates) - #139822 (Fix: Map EOPNOTSUPP to ErrorKind::Unsupported on Unix) - #139833 (Fix some HIR pretty-printing problems) - #139836 (Basic tests of MPMC receiver cloning) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-15Rollup merge of #139798 - lcnr:where-bounds-gt-alias-bound, r=compiler-errorsStuart Cook-0/+29
normalize: prefer `ParamEnv` over `AliasBound` candidates cc https://github.com/rust-lang/trait-system-refactor-initiative/issues/175 not the only issue affecting bevy sadly r? ``@compiler-errors``
2025-04-15Rollup merge of #139791 - lcnr:ignore-global-where-bounds, r=compiler-errorsStuart Cook-4/+87
drop global where-bounds before merging candidates fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/172 r? ```@compiler-errors```
2025-04-15Rollup merge of #139789 - lcnr:opaques-auto-trait-leakage, r=compiler-errorsStuart Cook-0/+260
do not unnecessarily leak auto traits in item bounds fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/158 Not a fix for https://github.com/rust-lang/trait-system-refactor-initiative/issues/173 as you may have realized/tried yourself, cc #139788. However, fixing this feels desirable regardless and I don't see any reason not to. r? ```@compiler-errors```
2025-04-15Rollup merge of #139671 - m-ou-se:proc-macro-span, r=dtolnayStuart Cook-26/+13
Proc macro span API redesign: Replace proc_macro::SourceFile by Span::{file, local_file} Simplification/redesign of the unstable proc macro span API, tracked in https://github.com/rust-lang/rust/issues/54725: Before: ```rust impl Span { pub fn line(&self) -> usize; pub fn column(&self) -> usize; pub fn source_file(&self) -> SourceFile; } #[derive(Clone, Debug, PartialEq, Eq)] pub struct SourceFile { .. } impl !Send for SourceFile {} impl !Sync for SourceFile {} impl SourceFile { pub fn path(&self) -> PathBuf; pub fn is_real(&self) -> bool; } ``` After: ```rust impl Span { pub fn line(&self) -> usize; pub fn column(&self) -> usize; pub fn file(&self) -> String; // Mapped file name, for display purposes. pub fn local_file(&self) -> Option<PathBuf>; // Real file name as it exists on disk. } ``` This resolves the last blocker for stabilizing these methods. (Stabilizing will be a separate PR with FCP.)
2025-04-15Rollup merge of #139669 - nnethercote:overhaul-AssocItem, r=oli-obkStuart Cook-4/+4
Overhaul `AssocItem` `AssocItem` has multiple fields that only make sense some of the time. E.g. the `name` can be empty if it's an RPITIT associated type. It's clearer and less error prone if these fields are moved to the relevant `kind` variants. r? ``@fee1-dead``
2025-04-15Rollup merge of #138393 - oli-obk:pattern-type-in-pattern, r=BoxyUwUStuart Cook-2/+197
Allow const patterns of matches to contain pattern types Trying to pattern match on a type containing a pattern type will currently fail with an ICE ```rust error: internal compiler error: compiler/rustc_mir_build/src/builder/matches/test.rs:459:18: invalid type for non-scalar compare: (u32) is 1.. --> src/main.rs:22:5 | 22 | TWO => {} | ^^^ ``` because the compiler tries to generate a MIR `BinOp(Eq)` operation on a pattern type, which is not supported. While we could support that, there are side effects of allowing this (none that would compile, but the compiler would simultaneously think it could `==` pattern types and that it could not because `PartialEq` is not implemented. So instead I change the logic for pattern matching to transmute pattern types to their base type before comparing. r? ```@BoxyUwU``` cc #123646 ```@scottmcm``` ```@joshtriplett```
2025-04-15Rollup merge of #138374 - celinval:issue-136925-const-contract, ↵Stuart Cook-7/+97
r=compiler-errors,oli-obk,RalfJung Enable contracts for const functions Use `const_eval_select!()` macro to enable contract checking only at runtime. The existing contract logic relies on closures, which are not supported in constant functions. This commit also removes one level of indirection for ensures clauses since we no longer build a closure around the ensures predicate. Resolves #136925 **Call-out:** This is still a draft PR since CI is broken due to a new warning message for unreachable code when the bottom of the function is indeed unreachable. It's not clear to me why the warning wasn't triggered before. r? ```@compiler-errors```
2025-04-15Auto merge of #139826 - matthiaskrgr:rollup-0q0qvkd, r=matthiaskrgrbors-32/+61
Rollup of 8 pull requests Successful merges: - #139745 (Avoid unused clones in `Cloned<I>` and `Copied<I>`) - #139757 (opt-dist: use executable-extension for host llvm-profdata) - #139778 (Add test for issue 34834) - #139783 (Use `compiletest-ignore-dir` for bootstrap self-tests) - #139797 (Allow (but don't require) `#[unsafe(naked)]` so that `compiler-builtins` can upgrade to it) - #139799 (Specify `--print info=file` syntax in `--help`) - #139811 (Use `newtype_index!`-generated types more idiomatically) - #139813 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-14Stabilize `-Zdwarf-version` as `-Cdwarf-version`Wesley Wiser-10/+10
2025-04-14Rollup merge of #139799 - clubby789:print=file, r=jieyouxuMatthias Krüger-2/+3
Specify `--print info=file` syntax in `--help` Closes #139794 I moved the listing of information that can be printed to the help string as it's getting rather long and it makes the `[=FILE]` part easier to see
2025-04-14Rollup merge of #139797 - folkertdev:naked-allow-unsafe, r=tgross35Matthias Krüger-28/+28
Allow (but don't require) `#[unsafe(naked)]` so that `compiler-builtins` can upgrade to it tracking issue: https://github.com/rust-lang/rust/issues/138997 Per https://github.com/rust-lang/rust/pull/134213#issuecomment-2755984503, we want to make the `#[naked]` attribute an unsafe attribute. Making that change runs into a cyclic dependency with `compiler-builtins` which uses `#[naked]`, where `rustc` needs an updated `compiler-builtins` and vice versa. So based on https://github.com/rust-lang/rust/pull/139753 and [#t-compiler/help > updating &#96;compiler-builtins&#96; and &#96;rustc&#96;](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/updating.20.60compiler-builtins.60.20and.20.60rustc.60), this PR allows, but does not require `#[unsafe(naked)]`, and makes that change for some of the tests to check that both `#[naked]` and `#[unsafe(naked)]` are accepted. Then we can upgrade and synchronize `compiler-builtins`, and then make `#[naked]` (without `unsafe`) invalid. r? `@traviscross` (or someone from t-compiler if you're faster and this look allright)
2025-04-14Rollup merge of #139783 - jieyouxu:ignore-dir, r=ZalatharMatthias Krüger-2/+0
Use `compiletest-ignore-dir` for bootstrap self-tests Follow-up to #139705 and #139740. I did another survey pass over `//@ ignore-test` under `tests/`, and this is the only 2 non-tests that should use `compiletest-ignore-dir`. r? `@Zalathar` (or compiler/bootstrap)
2025-04-14Rollup merge of #139778 - reddevilmidzy:add-success-test, r=lcnrMatthias Krüger-0/+30
Add test for issue 34834 closes: #34834 This PR adds a UI test for a case where a trait with an associated type using a higher-ranked trait bound (HRTB) failed to compile in Rust 1.55.0 but succeeded starting from 1.56.0. ```rust pub trait Provides<'a> { type Item; } pub trait Selector: for<'a> Provides<'a> { type Namespace: PartialEq + for<'a> PartialEq<<Self as Provides<'a>>::Item>; fn get_namespace(&self) -> <Self as Provides>::Item; } pub struct MySelector; impl<'a> Provides<'a> for MySelector { type Item = &'a str; } impl Selector for MySelector { type Namespace = String; fn get_namespace(&self) -> &str { unimplemented!() } } fn main() {} ``` * ❌ [compile fail (rustc: 1.55.0)](https://godbolt.org/z/T1jY1Ebo6) * ⭕ [compile pass (rustc: 1.56.0)](https://godbolt.org/z/e4jo11Ma7)
2025-04-14Auto merge of #139577 - davidtwco:sizedness-go-vroom, r=oli-obkbors-7/+14
re-use `Sized` fast-path There's an existing fast path for the `type_op_prove_predicate` predicate, checking for trivially `Sized` types, which can be re-used when evaluating obligations within queries. This should improve performance and was found to be beneficial in #137944. r? types
2025-04-14Allow (but don't require) `#[unsafe(naked)]` so that `compiler-builtins` can ↵Folkert de Vries-28/+28
upgrade to it
2025-04-14Normalize ADT fields in find_tails_for_unsizingMichael Goulet-0/+32
2025-04-14Auto merge of #139814 - matthiaskrgr:rollup-lxkkcz6, r=matthiaskrgrbors-0/+166
Rollup of 8 pull requests Successful merges: - #139127 (Fix up partial res of segment in primitive resolution hack) - #139392 (Detect and provide suggestion for `&raw EXPR`) - #139767 (Visit place in `BackwardIncompatibleDropHint` statement) - #139777 (Remove `define_debug_via_print` for `ExistentialProjection`, use regular structural debug impl) - #139796 (ptr docs: add missing backtics around 'usize') - #139801 (Add myself to mailmap) - #139804 (use `realpath` in `bootstrap.py` when creating build-dir) - #139807 (Improve wording of post-merge report) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-14Rollup merge of #139392 - compiler-errors:raw-expr, r=oli-obkMatthias Krüger-0/+140
Detect and provide suggestion for `&raw EXPR` When emitting an error in the parser, and we detect that the previous token was `raw` and we *could* have consumed `const`/`mut`, suggest that this may have been a mistyped raw ref expr. To do this, we add `const`/`mut` to the expected token set when parsing `&raw` as an expression (which does not affect the "good path" of parsing, for the record). This is kind of a rudimentary error improvement, since it doesn't actually attempt to recover anything, leading to some other knock-on errors b/c we still treat `&raw` as the expression that was parsed... but at least we add the suggestion! I don't think the parser grammar means we can faithfully recover `&raw EXPR` early, i.e. during `parse_expr_borrow`. Fixes #133231
2025-04-14Rollup merge of #139127 - compiler-errors:prim-ty-hack, r=oli-obkMatthias Krüger-0/+26
Fix up partial res of segment in primitive resolution hack There is a hack in the resolver: ``` // In `a(::assoc_item)*` `a` cannot be a module. If `a` does resolve to a module we // don't report an error right away, but try to fallback to a primitive type. ``` This fixes up the resolution for primitives which would otherwise resolve to a module, but we weren't also updating the res of the path segment, leading to weird diagnostics. We explicitly call `self.r.partial_res_map.insert` instead of `record_partial_res` b/c we have recorded a partial res already, and we specifically want to override it. cc https://github.com/rust-lang/rust/issues/139095#issuecomment-2764371934
2025-04-14Allow const patterns of matches to contain pattern typesOli Scherer-2/+197
2025-04-14Specify `--print info=file` syntax in `--help`clubby789-2/+3
2025-04-14Auto merge of #138603 - xizheyin:issue-137405, r=chenyukangbors-0/+91
Report line number of test when should_panic test failed Closes #137405 --- try-job: x86_64-gnu-llvm-19-3 try-job: test-various
2025-04-14normalize: prefer ParamEnv over AliasBoundlcnr-0/+29
2025-04-14add RPITIT tests: method compat auto trait leakagelcnr-0/+224
2025-04-14move testslcnr-0/+0
2025-04-14do not leak auto traits in item boundslcnr-0/+36
2025-04-14drop global where-bounds before merging candidateslcnr-4/+87
2025-04-14Handle regions equivalent to 'static in non_local_boundsMatthew Jasper-0/+169
`non_local_bounds` would only find non local bounds that strictly bound a given region, but it's possible that a local region is equated to 'static when showing a type referencing a locally bound lifetime, such as `dyn Any + 'a` in the tests added, is well-formed. In this case we should return 'static.
2025-04-14Add test for issue 34834reddevilmidzy-0/+30
2025-04-14tests: use `compiletest-ignore-dir` for bootstrap self-testsJieyou Xu-2/+0
2025-04-14Auto merge of #139781 - jhpratt:rollup-qadsjvb, r=jhprattbors-350/+439
Rollup of 9 pull requests Successful merges: - #138336 (Improve `-Z crate-attr` diagnostics) - #139636 (Encode dep node edge count as u32 instead of usize) - #139666 (cleanup `mir_borrowck`) - #139695 (compiletest: consistently use `camino::{Utf8Path,Utf8PathBuf}` throughout) - #139699 (Proactively update coroutine drop shim's phase to account for later passes applied during shim query) - #139718 (enforce unsafe attributes in pre-2024 editions by default) - #139722 (Move some things to rustc_type_ir) - #139760 (UI tests: migrate remaining compile time `error-pattern`s to line annotations when possible) - #139776 (Switch attrs to `diagnostic::on_unimplemented`) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-14Consistent with treating Ctor Call as Struct in liveness analysisxizheyin-39/+4
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>