https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=beta 2025-07-22T12:28:48+00:00 2025-07-22T12:28:48+00:00 Guillaume Gomez guillaume1.gomez@gmail.com 2025-07-21T12:34:12+00:00 urn:sha1:a27f3e3fd1e4d16160f8885b6b06665b5319f56c 2025-07-22T12:27:48+00:00 Guillaume Gomez guillaume1.gomez@gmail.com 2025-07-21T12:22:51+00:00 urn:sha1:ed93c1783b404d728d4809973a0550eb33cd293f 2025-07-21T16:54:28+00:00 许杰友 Jieyou Xu (Joe) 39484203+jieyouxu@users.noreply.github.com 2025-07-21T16:54:28+00:00 urn:sha1:ef4a7fb1b7f398565a038c1eb84da30e53006599 Mitigate `#[align]` name resolution ambiguity regression with a rename Mitigates beta regression rust-lang/rust#143834 after a beta backport. ### Background on the beta regression The name resolution regression arises due to rust-lang/rust#142507 adding a new feature-gated built-in attribute named `#[align]`. However, unfortunately even [introducing new feature-gated unstable built-in attributes can break user code](https://www.github.com/rust-lang/rust/issues/134963) such as ```rs macro_rules! align { () => { /* .. */ }; } pub(crate) use align; // `use` here becomes ambiguous ``` ### Mitigation approach This PR renames `#[align]` to `#[rustc_align]` to mitigate the beta regression by: 1. Undoing the introduction of a new built-in attribute with a common name, i.e. `#[align]`. 2. Renaming `#[align]` to `#[rustc_align]`. The renamed attribute being `rustc_align` will not introduce new stable breakages, as attributes beginning with `rustc` are reserved and perma-unstable. This does mean existing nightly code using `fn_align` feature will additionally need to specify `#![feature(rustc_attrs)]`. This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in [#t-lang > namespacing macro attrs to reduce conflicts with new adds](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/with/529249622). ### Alternative mitigation options [Various mitigation options were considered during the compiler triage meeting](https://github.com/rust-lang/rust/issues/143834#issuecomment-3084415277), and those consideration are partly reproduced here: - Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own. - Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying. - Rename the attribute to a rustc attribute, which will be perma-unstable and does not cause new ambiguities in stable code. - This alleviates the time pressure to address *this* regression, or for lang to have to rush an FCP for some new name that can still break user code. - This avoids backing out a whole implementation. ### Review advice This PR is best reviewed commit-by-commit. - Commit 1 adds a test `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` which demonstrates the current name resolution regression re. `align`. This test fails against current master. - Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` to change from fail (nameres regression) to pass. This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression. 2025-07-21T16:54:24+00:00 许杰友 Jieyou Xu (Joe) 39484203+jieyouxu@users.noreply.github.com 2025-07-21T16:54:24+00:00 urn:sha1:5e3eb2512591df0cef52404f0ea4202f58935a54 gpu offload host code generation r? ghost This will generate most of the host side code to use llvm's offload feature. The first PR will only handle automatic mem-transfers to and from the device. So if a user calls a kernel, we will copy inputs back and forth, but we won't do the actual kernel launch. Before merging, we will use LLVM's Info infrastructure to verify that the memcopies match what openmp offloa generates in C++. `LIBOMPTARGET_INFO=-1 ./my_rust_binary` should print that a memcpy to and later from the device is happening. A follow-up PR will generate the actual device-side kernel which will then do computations on the GPU. A third PR will implement manual host2device and device2host functionality, but the goal is to minimize cases where a user has to overwrite our default handling due to performance issues. I'm trying to get a full MVP out first, so this just recognizes GPU functions based on magic names. The final frontend will obviously move this over to use proper macros, like I'm already doing it for the autodiff work. This work will also be compatible with std::autodiff, so one can differentiate GPU kernels. Tracking: - https://github.com/rust-lang/rust/issues/131513 2025-07-20T17:22:09+00:00 Scott McMurray scottmcm@users.noreply.github.com 2025-03-07T03:13:46+00:00 urn:sha1:41ce1ed252f194756fb2f3e3e92bbdfb3940088d 2025-07-20T17:15:14+00:00 Scott McMurray scottmcm@users.noreply.github.com 2025-07-12T09:33:42+00:00 urn:sha1:08b816ff18347031b1160f1257cde2008c3c366e 2025-07-20T03:50:02+00:00 Scott McMurray scottmcm@users.noreply.github.com 2025-07-20T03:49:52+00:00 urn:sha1:4b8f869c638e6d5090420ff46bd14e7b7d909690 Looks like the output it's looking for can be in different orders, so separate tests will fix that. 2025-07-20T03:50:02+00:00 Scott McMurray scottmcm@users.noreply.github.com 2025-07-10T06:59:00+00:00 urn:sha1:0586c63e070981af7df53e2f778d3e50293d8103 The conversation in 143502 made be realize how easy this is to handle, since the only possibilty is ZSTs -- everything else ends up with the destination being `LocalKind::Memory` and thus doesn't call `codegen_rvalue_operand` at all. This gets us perilously close to a world where `rvalue_creates_operand` only ever returns true. I'll try out such a world next :) 2025-07-19T08:03:40+00:00 bors bors@rust-lang.org 2025-07-19T08:03:40+00:00 urn:sha1:83825dd277503edf5d7eda6be8b5fb9896f343f5 Simplify discriminant codegen for niche-encoded variants which don't wrap across an integer boundary Inspired by rust-lang/rust#139729, this attempts to be a much-simpler and more-localized change while still making a difference. (Specifically, this does not try to solve the problem with select-sinking, leaving that to be fixed by https://github.com/llvm/llvm-project/issues/134024 -- once it gets released -- instead of in rustc's codegen.) What this *does* improve is checking for the variant in a 3+ variant enum when that variant is the type providing the niche. Something like `if let Foo::WithBool(_) = ...` previously compiled to `ugt(add(x, -2), 2)`, which is non-trivial to think about because it's depending on the unsigned wrapping to shift the 0/1 up above 2. With this PR it compiles to just `ult(x, 2)`, which is probably what you'd have written yourself if you were doing it by hand to look for "is this byte a bool?". That's done by leaving most of the codegen alone, but adding a couple new special cases to the `is_niche` check. The default looks at the relative discriminant, but in the common cases where there's no wraparound involved, we can just check the original value, rather than the offsetted one. The first commit just adds some tests, so the best way to see the effect of this change is to look at the second commit and how it updates the test expectations. 2025-07-18T23:30:46+00:00 Manuel Drehwald git@manuel.drehwald.info 2025-07-18T23:00:04+00:00 urn:sha1:e2ab312c9408761faf64723c77cd4ba4a58792bc