https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.89.0 2025-06-19T18:02:04+00:00 2025-06-19T18:02:04+00:00 Cameron Steffen cam.steffen94@gmail.com 2025-06-19T18:02:04+00:00 urn:sha1:07b9bb1855596ac84a80d898b40c4b403f1dcc3f 2025-06-16T09:51:17+00:00 Jakub Beránek berykubik@gmail.com 2025-06-06T15:12:55+00:00 urn:sha1:c9d305952e0a74a5d0428fed79b62487aefa41e4 2025-06-15T21:51:54+00:00 León Orell Valerian Liehr me@fmease.dev 2025-06-15T21:51:54+00:00 urn:sha1:0b249d3f857b86887bae595d32b4c40235a32bf0 Move metadata object generation for dylibs to the linker code This deduplicates some code between codegen backends and may in the future allow adding extra metadata that is only known at link time. Prerequisite of https://github.com/rust-lang/rust/issues/96708. 2025-06-05T16:54:10+00:00 bjorn3 17426603+bjorn3@users.noreply.github.com 2025-06-05T16:53:12+00:00 urn:sha1:dff8ee5b01b7251937860da41afd55958c13456a Before this change we had two different ways to attempt to locate the sysroot which are inconsistently used: * get_or_default_sysroot which tries to locate based on the 0th cli argument and if that doesn't work falls back to locating it using the librustc_driver.so location and returns a single path., * sysroot_candidates which takes the former and additionally does another attempt at locating using librustc_driver.so except without linux multiarch handling and then returns both paths., The latter was originally introduced to be able to locate the codegen backend back when cg_llvm was dynamically linked even for a custom driver when the --sysroot passed in does not contain a copy of cg_llvm. Back then get_or_default_sysroot did not attempt to locate the sysroot based on the location of librustc_driver.so yet. Because that is now done, the only case where removing sysroot_candidates can break things is if you have a custom driver inside what looks like a sysroot including the lib/rustlib directory, but which is missing some parts of the full sysroot like eg rust-lld. 2025-06-03T10:04:34+00:00 bjorn3 17426603+bjorn3@users.noreply.github.com 2025-05-30T12:51:15+00:00 urn:sha1:0bd7aa1116c42a96d1c692065ae500a3d2d75484 This deduplicates some code between codegen backends and may in the future allow adding extra metadata that is only known at link time. 2025-05-27T13:33:29+00:00 Zalathar Zalathar@users.noreply.github.com 2025-05-27T13:25:57+00:00 urn:sha1:3f526eeec4efe8a31154b7b20b64d99c1badce9e This reverts commit 3b22c21dd8c30f499051fe7a758ca0e5d81eb638, reversing changes made to 5f292eea6d63abbd26f1e6e00a0b8cf21d828d7d. 2025-05-09T14:24:03+00:00 Zalathar Zalathar@users.noreply.github.com 2025-05-09T10:57:17+00:00 urn:sha1:078144fdfa7ae627d43cd919d660a71bef1e4658 This case can't actually happen yet (other than via a testing flag), because currently all of a function's spans must belong to the same file and expansion. But this will be an important edge case when adding expansion region support. 2025-04-15T02:26:41+00:00 Wesley Wiser wwiser@gmail.com 2025-02-12T14:06:34+00:00 urn:sha1:e21691529549152625a509e7e69af0b813420c53 2025-04-07T20:48:40+00:00 Michael Goulet michael@errs.io 2025-04-06T23:50:16+00:00 urn:sha1:9c372d8940a8dad14d586f6bd4dd42541f25cd80 2025-04-06T10:16:28+00:00 bors bors@rust-lang.org 2025-04-06T10:16:28+00:00 urn:sha1:f5c510260bef89f7799d0b8e1aa70d7d7925cd99 Refactor Apple version handling in the compiler Move various Apple version handling code in the compiler out `rustc_codegen_ssa` and into a place where it can be accessed by `rustc_attr_parsing`, which I found to be necessary when doing https://github.com/rust-lang/rust/pull/136867. Thought I'd split it out to make it easier to land, and to make further changes like https://github.com/rust-lang/rust/pull/131477 have fewer conflicts / PR dependencies. There should be no functional changes in this PR. `@rustbot` label O-apple r? rust-lang/compiler