https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=lcnr/rustc-dev-guide 2025-08-11T22:05:42+00:00 2025-08-11T22:05:42+00:00 Cameron Steffen cam.steffen94@gmail.com 2025-07-24T14:32:58+00:00 urn:sha1:bf266dc8341755f0f7ac6de1cfa474875f79b3d9 2025-08-09T03:19:26+00:00 bors bors@rust-lang.org 2025-08-09T03:19:26+00:00 urn:sha1:2de2456fb7b2b55cb104bb03f30edd145c6015a3 add a scope for `if let` guard temporaries and bindings This fixes my concern with `if let` guard drop order, namely that the guard's bindings and temporaries were being dropped after their arm's pattern's bindings, instead of before (https://github.com/rust-lang/rust/pull/141295#issuecomment-2968975596). The guard's bindings and temporaries now live in a new scope, which extends until (but not past) the end of the arm, guaranteeing they're dropped before the arm's pattern's bindings. This only introduces a new scope for match arms with guards. Perf results (https://github.com/rust-lang/rust/pull/143376#issuecomment-3034922617) seemed to indicate there wasn't a significant hit to introduce a new scope on all match arms, but guard patterns (rust-lang/rust#129967) will likely benefit from only adding new scopes when necessary (with some patterns requiring multiple nested scopes). Tracking issue for `if_let_guard`: rust-lang/rust#51114 Tests are adapted from examples by `@traviscross,` `@est31,` and myself on rust-lang/rust#141295. 2025-08-08T19:22:44+00:00 Trevor Gross t.gross35@gmail.com 2025-08-08T19:22:44+00:00 urn:sha1:6fa6a854cd791e9efa813e9b18cd1a5337ded971 atomicrmw on pointers: move integer-pointer cast hacks into backend Conceptually, we want to have atomic operations on pointers of the form `fn atomic_add(ptr: *mut T, offset: usize, ...)`. However, LLVM does not directly support such operations (https://github.com/llvm/llvm-project/issues/120837), so we have to cast the `offset` to a pointer somewhere. This PR moves that hack into the LLVM backend, so that the standard library, intrinsic, and Miri all work with the conceptual operation we actually want. Hopefully, one day LLVM will gain a way to represent these operations without integer-pointer casts, and then the hack will disappear entirely. Cc ```@nikic``` -- this is the best we can do right now, right? Fixes https://github.com/rust-lang/rust/issues/134617 2025-08-07T23:51:41+00:00 dianne diannes.gm@gmail.com 2025-08-07T23:17:54+00:00 urn:sha1:0bdaef5b63fe2d557483e72732e463b86ffb041b 2025-08-07T23:43:20+00:00 dianne diannes.gm@gmail.com 2025-07-03T13:10:37+00:00 urn:sha1:b2241c78c86a15b8e7e842f036135df4478de0fe This ensures `if let` guard temporaries and bindings are dropped before the match arm's pattern's bindings. 2025-08-04T04:58:09+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-08-04T04:58:09+00:00 urn:sha1:7307dc0ca1c04814517f2afe57b8aa12b2f9960b Distinguish prepending and replacing self ty in predicates There are two kinds of functions called `with_self_ty`: 1. Prepends the `Self` type onto an `ExistentialPredicate` which lacks it in its internal representation. 2. Replaces the `Self` type of an existing predicate, either for diagnostics purposes or in the new trait solver when normalizing that self type. This PR distinguishes these two because I often want to only grep for one of them. Namely, let's call it `with_replaced_self_ty` when all we're doing is replacing the self type. 2025-08-03T09:29:54+00:00 bors bors@rust-lang.org 2025-08-03T09:29:54+00:00 urn:sha1:7cd950546b4ce68843b4cbdb1ab3a43776202d3a expand WF obligations when checking method calls Don't wrap a bunch of signatures in `FnPtr` then check their WF; instead, check the WFness of each input/output separately. This is useful for the new trait solver, since because we stall on root obligations we end up needing to repeatedly recompute the WFness of possibly very large function signature types if it ends up bottoming out in ambiguity. This may also give us more chances to hit the WF fast path for certain types like built-ins. Finally, this just seems conceptually correct to do. There's nothing conceptually that suggests that wrapping the function signature in an fn pointer makes sense at all to do; I'm guessing that it was just convenient so that we didn't have to register WF obligations in a loop, but it doesn't affect the readability of this code at all. 2025-08-03T05:26:43+00:00 bors bors@rust-lang.org 2025-08-03T05:26:43+00:00 urn:sha1:da19b9d24c4ed900b91b45ec7f7795ec43613b1e Improve bound const handling A few changes to make const handling more similar to type handling. r? `@compiler-errors` -errors 2025-08-02T09:24:24+00:00 Samuel Tardieu sam@rfc1149.net 2025-08-02T09:24:24+00:00 urn:sha1:d082ff4c04c09e855d7ea55e0c9deda05eba46ec Improve formatting of doc code blocks We don't currently apply automatic formatting to doc comment code blocks. As a result, it has built up various idiosyncracies, which make such automatic formatting difficult. Some of those idiosyncracies also make things harder for human readers or other tools. This PR makes a few improvements to doc code formatting, in the hopes of making future automatic formatting easier, as well as in many cases providing net readability improvements. I would suggest reading each commit separately, as each commit contains one class of changes. 2025-07-31T12:19:27+00:00 Jana Dönszelmann jana@donsz.nl 2025-07-31T09:00:40+00:00 urn:sha1:e1d3ad89c7a2ad4f5d944a7fee1298ffe8c99645