https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.87.0 2025-03-12T07:04:09+00:00 2025-03-12T07:04:09+00:00 Ralf Jung post@ralfj.de 2025-03-12T07:03:54+00:00 urn:sha1:cf318a79d678bf8beec26a547b384975de5039b1 2025-02-24T06:53:59+00:00 Ralf Jung post@ralfj.de 2025-02-23T16:34:50+00:00 urn:sha1:6eea027aa9453b685ac636ea40fc826267afab2a 2025-02-13T03:45:04+00:00 Michael Goulet michael@errs.io 2025-02-06T20:08:29+00:00 urn:sha1:516afd557c521eae3a64882b93d32772f3e2fa45 2025-01-21T13:59:15+00:00 Ralf Jung post@ralfj.de 2024-12-14T08:13:12+00:00 urn:sha1:56c90dc31e86bbaf486826a21a33d7c56e8f742f 2025-01-15T09:08:10+00:00 Jacob Pratt jacob@jhpratt.dev 2025-01-15T09:08:10+00:00 urn:sha1:285df03257160fb62ea22b57a47f103739c5ba73 Make missing_abi lint warn-by-default. This makes the missing_abi lint warn-by-default, as suggested here: https://github.com/rust-lang/rfcs/pull/3722#issuecomment-2447719047 This needs a lang FCP. 2025-01-13T15:53:58+00:00 Antoni Boucher bouanto@zoho.com 2025-01-13T15:53:58+00:00 urn:sha1:06f0a9bc785ad8654e1bf505f60ce7146b3850f3 2025-01-07T15:04:14+00:00 Mara Bos m-ou.se@m-ou.se 2024-10-31T10:39:45+00:00 urn:sha1:585c9765a203df7cc7b497d848aae4ba979fcb39 2024-12-07T20:50:00+00:00 Jack Wrenn jack@wrenn.fyi 2024-12-06T17:11:36+00:00 urn:sha1:3ce35a4ec5f06828f908a018da083af5eb54301a As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also require `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block. For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields. Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`. This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields. Tracking: #132922 2024-11-08T08:16:00+00:00 Ralf Jung post@ralfj.de 2024-11-07T07:59:43+00:00 urn:sha1:e3010e84dbf2e06424c91c5a3d4206c1911813bd 2024-10-22T12:55:16+00:00 Adrian Taylor adetaylor@chromium.org 2024-09-11T12:27:08+00:00 urn:sha1:8f85b90ca6d57459eb19accb6aaf781dd1c7bf6c As part of the "arbitrary self types v2" project, we are going to replace the current `Receiver` trait with a new mechanism based on a new, different `Receiver` trait. This PR renames the old trait to get it out the way. Naming is hard. Options considered included: * HardCodedReceiver (because it should only be used for things in the standard library, and hence is sort-of hard coded) * LegacyReceiver * TargetLessReceiver * OldReceiver These are all bad names, but fortunately this will be temporary. Assuming the new mechanism proceeds to stabilization as intended, the legacy trait will be removed altogether. Although we expect this trait to be used only in the standard library, we suspect it may be in use elsehwere, so we're landing this change separately to identify any surprising breakages. It's known that this trait is used within the Rust for Linux project; a patch is in progress to remove their dependency. This is a part of the arbitrary self types v2 project, https://github.com/rust-lang/rfcs/pull/3519 https://github.com/rust-lang/rust/issues/44874 r? @wesleywiser