https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=auto 2025-10-04T10:31:27+00:00 2025-10-04T10:31:27+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-10-04T10:31:27+00:00 urn:sha1:82ccda32f48d52d1cadd0eb7826e72bf5f83bf9b interpret `#[used]` as `#[used(compiler)]` on illumos helps rust-lang/rust#146169 not be as painful: fixes the illumos regression in rust-lang/rust#140872, but `#[used(linker)]` is still erroneous on illumos generally. illumos' `ld` does not support a flag like either SHF_GNU_RETAIN or SHF_SUNW_NODISCARD, so there is no way to communicate `#[used(linker)]` for that target. Setting `USED_LINKER` to try results in LLVM setting SHF_SUNW_NODISCARD for Solaris-like targets, which is an unknown section header flag for illumos `ld` and prevents sections from being merged that otherwise would. As a motivating example, the `inventory` crate produces `#[used]` items to merge into `.init_array`. Because those items have an unknown section header flag they are not merged with the default `.init_array` with `frame_dummy`, and end up never executed. Downgrading `#[used]` to `#[used(compiler)]` on illumos keeps so-attributed items as preserved as they had been before https://github.com/rust-lang/rust/pull/140872. As was the case before that change, because rustc passes `-z ignore` to illumos `ld`, it's possible that `used` sections are GC'd at link time. https://github.com/rust-lang/rust/issues/146169 describes this unfortunate circumstance. ---- as it turns out, `tests/ui/attributes/used_with_archive.rs` had broken on `x86_64-unknown-illumos`, and this patch fixes it. the trials and tribulations of tier 2 :( r? ``@Noratrieb`` probably? 2025-10-03T22:03:24+00:00 iximeow iximeow@oxide.computer 2025-09-28T03:21:45+00:00 urn:sha1:c721fa243825255c0f195d4282021e7c263c3e7f illumos' `ld` does not support a flag like either SHF_GNU_RETAIN or SHF_SUNW_NODISCARD, so there is no way to communicate `#[used(linker)]` for that target. Setting `USED_LINKER` to try results in LLVM setting SHF_SUNW_NODISCARD for Solaris-like targets, which is an unknown section header flag for illumos `ld` and prevents sections from being merged that otherwise would. As a motivating example, the `inventory` crate produces `#[used]` items to merge into `.init_array`. Because those items have an unknown section header flag they are not merged with the default `.init_array` with `frame_dummy`, and end up never executed. Downgrading `#[used]` to `#[used(compiler)]` on illumos keeps so-attributed items as preserved as they had been before https://github.com/rust-lang/rust/pull/140872. As was the case before that change, because rustc passes `-z ignore` to illumos `ld`, it's possible that `used` sections are GC'd at link time. https://github.com/rust-lang/rust/issues/146169 describes this unfortunate circumstance. 2025-10-03T11:49:42+00:00 bors bors@rust-lang.org 2025-10-03T11:49:42+00:00 urn:sha1:8b6b15b877fbceb1ee5d9a5a4746e7515901574a Introduce debuginfo to statements in MIR The PR introduces support for debug information within dead statements. Currently, only the reference statement is supported, which is sufficient to fix rust-lang/rust#128081. I don't modify Stable MIR, as I don't think we need debug information when using it. This PR represents the debug information for the dead reference statement via `#dbg_value`. For example, `let _foo_b = &foo.b` becomes `#dbg_value(ptr %foo, !22, !DIExpression(DW_OP_plus_uconst, 4, DW_OP_stack_value), !26)`. You can see this here: https://rust.godbolt.org/z/d43js6adv. The general principle for handling debug information is to never provide less debug information than the optimized LLVM IR. The current rules for dropping debug information in this PR are: - If the LLVM IR cannot represent a reference address, it's replaced with poison or simply dropped. For example, see: https://rust.godbolt.org/z/shGqPec8W. I'm using poison in all such cases now. - All debuginfos is dropped when merging multiple successor BBs. An example is available here: https://rust.godbolt.org/z/TE1q3Wq6M. I doesn't drop debuginfos in `MatchBranchSimplification`, because LLVM also pick one branch for it. 2025-10-03T00:08:22+00:00 dianqk dianqk@dianqk.net 2025-09-21T12:58:34+00:00 urn:sha1:c2a03cefd8899941032940df0c6be3b364de0ed0 If the `LocalRef` is `LocalRef::Place`, we can refer to it directly, because the local of place is an indirect pointer. Such a statement is `_1 = &(_2.1)`. If the `LocalRef` is `LocalRef::Operand`, the `OperandRef` should provide the pointer of the reference. Such a statement is `_1 = &((*_2).1)`. But there is a special case that hasn't been handled, scalar pairs like `(&[i32; 16], i32)`. 2025-10-02T08:27:52+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-10-02T08:27:52+00:00 urn:sha1:8a18176c92af8ee396049b3f3b70721f2124d663 Don't enable shared memory by default with Wasm atomics This prepares us for a future where LLVM eventually stabilizes the atomics target feature, in which case we don't want to inflate atomics with threads. Otherwise users would be stuck with shared memory even when they don't want it/need it. ### Context Currently the atomics target features is unstable and can't be used without re-building Std with it (`-Zbuild-std`). Enabling the atomics target feature automatically enables shared memory. Shared memory is required to actually allow multi-threading. However, shared memory comes with a performance overhead when atomic instructions aren't able to be lowered to regular memory access instructions or when interacting with certain Web APIs. So it is very undesirable to enable shared memory by default for the majority of users. While it is possible to use atomics without shared memory, the question remains what use-case this scenario has. The only one I can think of would involve multiple memories, where the main memory remains un-shared but a second shared memory exists. While Rust doesn't support multiple memories, it might be possible with inline assembly (rust-lang/rust#136382). So alternatively, we might consider *not* enabling atomics by default even when LLVM does. In which case everything would remain the same. --- This will break current Web multi-threading users. To address this they can add the following `RUSTFLAGS`: ``` -Clink-args=--shared-memory,--max-memory=1073741824,--import-memory,--export=__wasm_init_tls,--export=__tls_size,--export=__tls_align,--export=__tls_base ``` We could add a new experimental flag that enables the right linker arguments for users, but I feel that's not in Rusts scope. Or like suggested before: a Rust-only `threads` target feature. Addresses rust-lang/rust#77839. r? ``@alexcrichton`` 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-06-18T14:04:48+00:00 urn:sha1:1bd89bd42e0bb6f29b8af5d6bdf3f756196bb8ee 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-10-01T13:36:47+00:00 daxpedda daxpedda@gmail.com 2025-10-01T12:47:42+00:00 urn:sha1:5b809b355c5c134e6848f800a2f8e692a3c10d44