https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=perf-tmp 2025-10-02T06:58:59+00:00 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-30T01:37:50+00:00 Jacob Pratt jacob@jhpratt.dev 2025-09-30T01:37:50+00:00 urn:sha1:b310eb91ab6fcf5619112a560f4266f42fe46c66 Skip cleanups on unsupported targets This commit is an update to the `AbortUnwindingCalls` MIR pass in the compiler. Specifically a new boolean is added for "can this target possibly unwind" and if that's `false` then terminators are all adjusted to be unreachable/not present. The end result is that this fixes rust-lang/rust#140293 for wasm targets. The motivation for this PR is that currently on WebAssembly targets the usage of the `C-unwind` ABI can lead LLVM to either (a) emit exception-handling instructions or (b) hit a LLVM-ICE-style codegen error. WebAssembly as a base instruction set does not support unwinding at all, and a later proposal to WebAssembly, the exception-handling proposal, was what enabled this. This means that the current intent of WebAssembly targets is that they maintain the baseline of "don't emit exception-handling instructions unless enabled". The commit here is intended to restore this behavior by skipping these instructions even when `C-unwind` is present. Exception-handling is a relatively tricky and also murky topic in WebAssembly, however. There are two sets of instructions LLVM can emit for WebAssembly exceptions, Rust's Emscripten target supports exceptions, WASI targets do not, the LLVM flags to enable this are not always obvious, and additionally this all touches on "changing exception-handling behavior should be a target-level concern, not a feature". Effectively WebAssembly's exception-handling integration into Rust is not finalized at this time. The best idea at this time is that a parallel set of targets will eventually be added which support exceptions, but it's not clear if/when to do this. In the meantime the goal is to keep existing targets working while still enabling experimentation with exception-handling with `-Zbuild-std` and various permutations of LLVM flags. To that extent this commit does not blanket disable these landing pads and cleanup routines for WebAssembly but instead checks to see if panic=unwind is enabled or if `+exception-handling` is enabled. Tests are updated here as well to account for this where, by default, using a `C-unwind` ABI won't affect Rust codegen at all. If `+exception-handling` is enabled, however, then Rust codegen will look like native platforms where exceptions are caught and the program aborts. More-or-less I've done my best to keep exceptions working on wasm where it's possible to have them work, but turned them off where they're not supposed to be emitted. Closes rust-lang/rust#140293 2025-09-29T19:42:43+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-09-29T19:42:43+00:00 urn:sha1:fdb965f3f76e0bbb75ef20ddae033b7e689c7d3c Use MirPatch in simplify_branches. This allows to avoid clearing the CFG cache if we don't perform any change. r? ``@ghost`` for perf 2025-09-28T22:02:14+00:00 Jubilee Young workingjubilee@gmail.com 2025-09-28T21:40:39+00:00 urn:sha1:0c9d0dfe046f0674f0507df564504ac3bac862d9 Much of the compiler calls functions on Align projected from AbiAlign. AbiAlign impls Deref to its inner Align, so we can simplify these away. Also, it will minimize disruption when AbiAlign is removed. For now, preserve usages that might resolve to PartialOrd or PartialEq, as those have odd inference. 2025-09-28T19:52:28+00:00 Camille Gillot gillot.camille@gmail.com 2025-09-27T00:14:32+00:00 urn:sha1:599e8db8389111d5c27934c5294879d9caf262e1 2025-09-26T20:44:06+00:00 Camille Gillot gillot.camille@gmail.com 2025-09-26T20:44:06+00:00 urn:sha1:d13a5b0a6c12837007c51f229cb8c58b614cfb5b