https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=perf-tmp 2025-10-03T11:49:42+00:00 2025-10-03T11:49:42+00:00 bors bors@rust-lang.org 2025-10-03T11:49:42+00:00 urn:sha1:8b6b15b877fbceb1ee5d9a5a4746e7515901574a Introduce debuginfo to statements in MIR The PR introduces support for debug information within dead statements. Currently, only the reference statement is supported, which is sufficient to fix rust-lang/rust#128081. I don't modify Stable MIR, as I don't think we need debug information when using it. This PR represents the debug information for the dead reference statement via `#dbg_value`. For example, `let _foo_b = &foo.b` becomes `#dbg_value(ptr %foo, !22, !DIExpression(DW_OP_plus_uconst, 4, DW_OP_stack_value), !26)`. You can see this here: https://rust.godbolt.org/z/d43js6adv. The general principle for handling debug information is to never provide less debug information than the optimized LLVM IR. The current rules for dropping debug information in this PR are: - If the LLVM IR cannot represent a reference address, it's replaced with poison or simply dropped. For example, see: https://rust.godbolt.org/z/shGqPec8W. I'm using poison in all such cases now. - All debuginfos is dropped when merging multiple successor BBs. An example is available here: https://rust.godbolt.org/z/TE1q3Wq6M. I doesn't drop debuginfos in `MatchBranchSimplification`, because LLVM also pick one branch for it. 2025-10-02T08:09:33+00:00 bors bors@rust-lang.org 2025-10-02T08:09:33+00:00 urn:sha1:4b9c62b4da3e17cee99d3d2052f1c576b188e2a8 Split Bound index into Canonical and Bound See [#t-types/trait-system-refactor > perf `async-closures/post-mono-higher-ranked-hang.rs`](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/perf.20.60async-closures.2Fpost-mono-higher-ranked-hang.2Ers.60/with/541535613) for context Things compile and tests pass, but not sure if this actually solves the perf issue (edit: it does). Opening up this to do a perf (and maybe crater) run. r? lcnr 2025-10-02T06:58:59+00:00 dianqk dianqk@dianqk.net 2025-07-19T10:49:47+00:00 urn:sha1:8da04285cf6fe61587e16155a8b224dba64bf0be 2025-10-02T06:55:51+00:00 dianqk dianqk@dianqk.net 2025-07-15T14:54:54+00:00 urn:sha1:85b2f706939528b5796d98e82c183637f8338cd1 2025-10-02T06:55:50+00:00 dianqk dianqk@dianqk.net 2025-07-10T13:20:54+00:00 urn:sha1:cc93132ae4f5477297ecddb0c07d2e8c74075f0c 2025-10-02T06:55:50+00:00 dianqk dianqk@dianqk.net 2025-06-08T07:30:09+00:00 urn:sha1:571412f8190089c36758031fe09fc0ece59be6b7 2025-10-02T01:54:48+00:00 bors bors@rust-lang.org 2025-10-02T01:54:48+00:00 urn:sha1:42b384ec0dfcd528d99a4db0a337d9188a9eecaa Turn ProjectionElem::Subtype into CastKind::Subtype I noticed that drop elaboration can't, in general, handle `ProjectionElem::SubType`. It creates a disjoint move path that overlaps with other move paths. (`Subslice` does too, and I'm working on a different PR to make that special case less fragile.) If its skipped and treated as the same move path as its parent then `MovePath.place` has multiple possible projections. (It would probably make sense to remove all `Subtype` projections for the canonical place but it doesn't make sense to have this special case for a problem that doesn't actually occur in real MIR.) The only reason this doesn't break is that `Subtype` is always the sole projection of the local its applied to. For the same reason, it works fine as a `CastKind` so I figured that makes more sense than documenting and validating this hidden invariant. cc rust-lang/rust#112651, rust-lang/rust#133258 r? Icnr (bc you've been the main person dealing with `Subtype` it looks like) 2025-09-30T16:58:28+00:00 jackh726 git@jackhuey.me 2025-09-28T23:04:55+00:00 urn:sha1:d1bbd39c59523d7a5499816a9da200a5910f8b7f 2025-09-30T12:25:17+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-09-30T12:25:17+00:00 urn:sha1:156d150381ab2e5f2dc2c78eb83b76d7ae95733c Rename various "concrete opaque type" things to say "hidden type" r? lcnr I've found "concrete opaque type" terminology to be somewhat confusing as in conversation and when explaining opaque type stuff to people I always just talk about things in terms of hidden types. Also the hidden types of opaques are very much not *concrete* in the same sense that a type without any generic parameters is concrete which is an unfortunate overlap in terminology. I've tried to update comments to also stop referring to things as concrete opaque types but this is mostly best effort as it difficult to find all such cases amongst the massive amounts of uses of "concrete" or "hidden" across the whole compiler. 2025-09-29T15:06:25+00:00 Boxy Uwu rust@boxyuwu.dev 2025-09-29T15:05:44+00:00 urn:sha1:66b664c9961e54282fbaccef72f90dfa7dd1418f