https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=try 2025-07-09T16:37:11+00:00 2025-07-09T16:37:11+00:00 Oli Scherer github333195615777966@oli-obk.de 2025-03-12T10:26:37+00:00 urn:sha1:486ffda9dcd0d4ef0a09d81e6ce5f241e77526a1 2025-07-03T07:51:06+00:00 klensy klensy@users.noreply.github.com 2024-12-07T10:51:08+00:00 urn:sha1:c76d032f0144b650a438ee1efba89c475e0b115b 2025-07-01T19:00:21+00:00 Michael Goulet michael@errs.io 2025-06-26T02:01:38+00:00 urn:sha1:2516c339829cd9193c15464218a981b8547157ca 2025-06-28T10:25:00+00:00 bors bors@rust-lang.org 2025-06-28T10:25:00+00:00 urn:sha1:b63223c152212832ce37a109e26cc5f84c577532 Insert checks for enum discriminants when debug assertions are enabled Similar to the existing null-pointer and alignment checks, this checks for valid enum discriminants on creation of enums through unsafe transmutes. Essentially this sanitizes patterns like the following: ```rust let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) }; ``` An extension of this check will be done in a follow-up that explicitly sanitizes for extern enum values that come into Rust from e.g. C/C++. This check is similar to Miri's capabilities of checking for valid construction of enum values. This PR is inspired by saethlin@'s PR https://github.com/rust-lang/rust/pull/104862. Thank you so much for keeping this code up and the detailed comments! I also pair-programmed large parts of this together with vabr-g@. r? `@saethlin` 2025-06-27T12:57:05+00:00 bors bors@rust-lang.org 2025-06-27T12:57:05+00:00 urn:sha1:13c46fd0b089360922a557d8e18a63a2c41dfbeb Stop collecting unmentioned constants This avoids generating useless dead LLVM IR. This appears to have regressed and/or been introduced in rust-lang/rust#53821 (unfortunately a very large PR - I don't see any direct discussion there of this particular change), but as far as I can tell is at least no longer necessary -- or we lack test coverage -- because none of our UI tests indicate diagnostics regressions. The adjusted codegen-units test has comments explicitly noting that these items should *not* be collected ("These are not referenced, so they do not produce mono-items"). I noticed this while looking at libcore LLVM IR we generate, which contained dead code references to the NOOP Waker item, which is never used inside libcore. Producing LLVM IR for it during libcore's compilation, only for that IR to get deleted by LLVM as unused, isn't useful. Note that the IR is generally all marked internal, too. 2025-06-27T09:37:36+00:00 Bastian Kersting bkersting@google.com 2025-05-15T19:09:13+00:00 urn:sha1:1087042e22ae3d14ff856f621a84eaa3e15cc537 Similar to the existing nullpointer and alignment checks, this checks for valid enum discriminants on creation of enums through unsafe transmutes. Essentially this sanitizes patterns like the following: ```rust let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) }; ``` An extension of this check will be done in a follow-up that explicitly sanitizes for extern enum values that come into Rust from e.g. C/C++. This check is similar to Miri's capabilities of checking for valid construction of enum values. This PR is inspired by saethlin@'s PR https://github.com/rust-lang/rust/pull/104862. Thank you so much for keeping this code up and the detailed comments! I also pair-programmed large parts of this together with vabr-g@. 2025-06-22T21:52:49+00:00 Mark Rousskov mark.simulacrum@gmail.com 2025-06-22T21:51:56+00:00 urn:sha1:928564c7bfb395e1e5bd34d8913b7627ee4d1130 This avoids generating useless dead LLVM IR. 2025-06-21T22:59:36+00:00 Mark Rousskov mark.simulacrum@gmail.com 2025-06-14T14:22:49+00:00 urn:sha1:1f405735078ac34be300fd2bd7c532aaa0bb6fc5 Since 122662 this no longer gets used in vtables, so we're safe to fully drop generating these empty functions. Those are eventually cleaned up by LLVM, but it's wasteful to produce them in the first place. This also adds a missing test for fn-ptr casts, which do still need to generate no-op drop glue. It's possible a future optimization could point all of those at the same drop glue (e.g., for *mut ()) rather than for each separate type, but that would require extra work for CFI and isn't particularly easy to do anyway. 2025-06-14T09:57:06+00:00 bjorn3 17426603+bjorn3@users.noreply.github.com 2024-12-06T09:06:51+00:00 urn:sha1:3e944fa3917a58e30d970d2cce42c14c5edf390b 2025-06-07T05:05:45+00:00 Jacob Pratt jacob@jhpratt.dev 2025-06-07T05:05:45+00:00 urn:sha1:9f35917dd958307b128da331d2c0fad0ac63515a Limit the size of cgu names when using the `-Zhuman-readable-cgu-name… …s` option Prior to this change, cgu names could be generated which would result in filenames longer than the limit imposed by the OS.