https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=beta 2025-09-06T13:31:41+00:00 2025-09-06T13:31:41+00:00 bjorn3 17426603+bjorn3@users.noreply.github.com 2025-09-05T19:09:39+00:00 urn:sha1:2cf94b92ca852924ad90943a0c469f01742216a6 2025-09-04T08:21:10+00:00 bjorn3 17426603+bjorn3@users.noreply.github.com 2025-08-28T10:26:29+00:00 urn:sha1:319fe230f0d960b343be31a1182dc0f10753156c A lot of places had special handling just in case they would get an allocator module even though most of these places could never get one or would have a trivial implementation for the allocator module. Moving all handling of the allocator module to a single place simplifies things a fair bit. 2025-08-31T23:19:03+00:00 Nicholas Nethercote n.nethercote@gmail.com 2025-08-15T04:38:17+00:00 urn:sha1:5ce3797073ee5e6cc487b80effbc682533d9425c MIR dumping is a mess. There are lots of functions and entry points, e.g. `dump_mir`, `dump_mir_with_options`, `dump_polonius_mir`, `dump_mir_to_writer`. Also, it's crucial that `create_dump_file` is never called without `dump_enabled` first being checked, but there is no mechanism for ensuring this and it's hard to tell if it is satisfied on all paths. (`dump_enabled` is checked twice on some paths, however!) This commit introduces `MirWriter`, which controls the MIR writing, and encapsulates the `extra_data` closure and `options`. Two existing functions are now methods of this type. It sets reasonable defaults, allowing the removal of many `|_, _| Ok(())` closures. The commit also introduces `MirDumper`, which is layered on top of `MirWriter`, and which manages the creation of the dump files, encapsulating pass names, disambiguators, etc. Four existing functions are now methods of this type. - `MirDumper::new` will only succeed if dumps are enabled, and will return `None` otherwise, which makes it impossible to dump when you shouldn't. - It also sets reasonable defaults for various things like disambiguators, which means you no longer need to specify them in many cases. When they do need to be specified, it's now done via setter methods. - It avoids some repetition. E.g. `dump_nll_mir` previously specifed the pass name `"nll"` four times and the disambiguator `&0` three times; now it specifies them just once, to put them in the `MirDumper`. - For Polonius, the `extra_data` closure can now be specified earlier, which avoids having to pass some arguments through some functions. 2025-08-31T22:52:34+00:00 Nicholas Nethercote n.nethercote@gmail.com 2025-08-14T23:13:23+00:00 urn:sha1:d7faa5630daf13c3d298e81ac329bf048a0d5a01 2025-08-13T19:01:37+00:00 Sasha Pourcelot sasha.pourcelot@protonmail.com 2025-08-12T18:22:45+00:00 urn:sha1:d435197afcb019a692aa1faf8b7169e167ac1de8 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-07T13:41:17+00:00 bjorn3 17426603+bjorn3@users.noreply.github.com 2025-08-07T13:13:04+00:00 urn:sha1:6c02653c4a564a2a1509dc55bdec2e5b8f02bdd9 The implementation of the linkage attribute inside extern blocks defines symbols starting with _rust_extern_with_linkage_. If someone tries to also define this symbol you will get a symbol conflict or even an ICE. By adding an unpredictable component to the symbol name, this becomes less of an issue. 2025-07-23T23:54:37+00:00 Camille GILLOT gillot.camille@gmail.com 2025-07-03T18:41:12+00:00 urn:sha1:0460c92d527dbada3fde227d3f01e6d1e132a186 2025-07-23T23:54:37+00:00 Camille GILLOT gillot.camille@gmail.com 2023-10-13T20:20:57+00:00 urn:sha1:9ff071219bca913e45235568defadd5ab840c50a 2025-07-23T06:32:55+00:00 Ralf Jung post@ralfj.de 2025-07-19T21:23:40+00:00 urn:sha1:de1b999ff6c981475e4491ea2fff1851655587e5