Add announcement for rust-lld on linux nightlies
#1319
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Mark-Simulacrum
approved these changes
Apr 27, 2024
lqd
force-pushed
the
rust-lld-announcement
branch
from
afbb1fd
to
6c7b7f6
Compare
nicoburns
reviewed
Apr 30, 2024
pnkfelix
reviewed
Apr 30, 2024
davidtwco
reviewed
May 2, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 16, 2024
Enable `rust-lld` on nightly `x86_64-unknown-linux-gnu` We believe we have done virtually all the internal work and tests we could to prepare for using `lld` as the default linker (at least on Linux). We're IMHO at a point where we'd need to expand testing and coverage in order to make progress on this effort. Therefore, for further testing and gathering real-world feedback, unexpected issues and use-cases, this PR enables `rust-lld` as the default linker: - on nightly only (and dev channel) - on `x86_64-unknown-linux-gnu` only - when not using an external LLVM (except `download-ci-llvm`), so that distros are not impacted as described in more detail in this [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Enabling.20.60rust-lld.60.20on.20nightly.20.60x86_64-unknown-linux-gnu.60/near/433709343). In case any issues happen to users, as e.g. lld is not bug-for-bug compatible with GNU ld, it's easy to disable with `-Zlinker-features=-lld` to revert to using the system's default linker. --- I don't know who should review this kind of things, as it's somewhat of a crosscutting effort. Compiler contributor, compiler performance WG and infra member sounds perfect, so r? `@Mark-Simulacrum.` The last crater run encountered a low number (44) of mainly avoidable issues, like small incompatibilities, user errors, and a difference between the two linkers about which default to use with `--gc-sections`. [Here's the triage report](https://hackmd.io/OAJxlxc6Te6YUot9ftYSKQ?view), categorizing the issues, with some analyses and workarounds. I'd appreciate another set of eyes looking at these results. The changes in this PR have been test-driven for CI changes, try builds with tests enabled, rustc-perf with bootstrapping, in PR rust-lang#113382. For infra, about the CI change: this PR forces `rust.lld` to false on vanilla LLVM builders, just to make sure we have coverage without `rust-lld`. Though to be clear, just using an external LLVM is already enough to keep `rust.lld` to false, in turn reverting everything to using the system's default linker. cc `@rust-lang/bootstrap` for the bootstrap and config change cc `@petrochenkov` for the small compiler change cc `@rust-lang/wg-compiler-performance` The blog post announcing the change, that we expect to merge around the same time as we merge this PR, is open [on the blog repo](rust-lang/blog.rust-lang.org#1319). Bootstrap change history: this PR changes the default of a config option on `x86_64-unknown-linux-gnu`. It's, however, not expected to cause issues, or require any changes to existing configurations. It's a big enough change that people should at least know about it, in case it causes unexpected problems. If that happens, set `rust.lld = false` in your `config.toml` (and open an issue).
Co-authored-by: Felix S Klock II <pnkfelix@pnkfx.org>
Co-authored-by: David Wood <agile.lion3441@fuligin.ink>
lqd
force-pushed
the
rust-lld-announcement
branch
from
587d0f6
to
ee913e7
Compare
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 16, 2024
Enable `rust-lld` on nightly `x86_64-unknown-linux-gnu` We believe we have done virtually all the internal work and tests we could to prepare for using `lld` as the default linker (at least on Linux). We're IMHO at a point where we'd need to expand testing and coverage in order to make progress on this effort. Therefore, for further testing and gathering real-world feedback, unexpected issues and use-cases, this PR enables `rust-lld` as the default linker: - on nightly only (and dev channel) - on `x86_64-unknown-linux-gnu` only - when not using an external LLVM (except `download-ci-llvm`), so that distros are not impacted as described in more detail in this [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Enabling.20.60rust-lld.60.20on.20nightly.20.60x86_64-unknown-linux-gnu.60/near/433709343). In case any issues happen to users, as e.g. lld is not bug-for-bug compatible with GNU ld, it's easy to disable with `-Zlinker-features=-lld` to revert to using the system's default linker. --- I don't know who should review this kind of things, as it's somewhat of a crosscutting effort. Compiler contributor, compiler performance WG and infra member sounds perfect, so r? `@Mark-Simulacrum.` The last crater run encountered a low number (44) of mainly avoidable issues, like small incompatibilities, user errors, and a difference between the two linkers about which default to use with `--gc-sections`. [Here's the triage report](https://hackmd.io/OAJxlxc6Te6YUot9ftYSKQ?view), categorizing the issues, with some analyses and workarounds. I'd appreciate another set of eyes looking at these results. The changes in this PR have been test-driven for CI changes, try builds with tests enabled, rustc-perf with bootstrapping, in PR rust-lang#113382. For infra, about the CI change: this PR forces `rust.lld` to false on vanilla LLVM builders, just to make sure we have coverage without `rust-lld`. Though to be clear, just using an external LLVM is already enough to keep `rust.lld` to false, in turn reverting everything to using the system's default linker. cc `@rust-lang/bootstrap` for the bootstrap and config change cc `@petrochenkov` for the small compiler change cc `@rust-lang/wg-compiler-performance` The blog post announcing the change, that we expect to merge around the same time as we merge this PR, is open [on the blog repo](rust-lang/blog.rust-lang.org#1319). Bootstrap change history: this PR changes the default of a config option on `x86_64-unknown-linux-gnu`. It's, however, not expected to cause issues, or require any changes to existing configurations. It's a big enough change that people should at least know about it, in case it causes unexpected problems. If that happens, set `rust.lld = false` in your `config.toml` (and open an issue).
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 17, 2024
Enable `rust-lld` on nightly `x86_64-unknown-linux-gnu` We believe we have done virtually all the internal work and tests we could to prepare for using `lld` as the default linker (at least on Linux). We're IMHO at a point where we'd need to expand testing and coverage in order to make progress on this effort. Therefore, for further testing and gathering real-world feedback, unexpected issues and use-cases, this PR enables `rust-lld` as the default linker: - on nightly only (and dev channel) - on `x86_64-unknown-linux-gnu` only - when not using an external LLVM (except `download-ci-llvm`), so that distros are not impacted as described in more detail in this [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Enabling.20.60rust-lld.60.20on.20nightly.20.60x86_64-unknown-linux-gnu.60/near/433709343). In case any issues happen to users, as e.g. lld is not bug-for-bug compatible with GNU ld, it's easy to disable with `-Zlinker-features=-lld` to revert to using the system's default linker. --- I don't know who should review this kind of things, as it's somewhat of a crosscutting effort. Compiler contributor, compiler performance WG and infra member sounds perfect, so r? `@Mark-Simulacrum.` The last crater run encountered a low number (44) of mainly avoidable issues, like small incompatibilities, user errors, and a difference between the two linkers about which default to use with `--gc-sections`. [Here's the triage report](https://hackmd.io/OAJxlxc6Te6YUot9ftYSKQ?view), categorizing the issues, with some analyses and workarounds. I'd appreciate another set of eyes looking at these results. The changes in this PR have been test-driven for CI changes, try builds with tests enabled, rustc-perf with bootstrapping, in PR rust-lang#113382. For infra, about the CI change: this PR forces `rust.lld` to false on vanilla LLVM builders, just to make sure we have coverage without `rust-lld`. Though to be clear, just using an external LLVM is already enough to keep `rust.lld` to false, in turn reverting everything to using the system's default linker. cc `@rust-lang/bootstrap` for the bootstrap and config change cc `@petrochenkov` for the small compiler change cc `@rust-lang/wg-compiler-performance` The blog post announcing the change, that we expect to merge around the same time as we merge this PR, is open [on the blog repo](rust-lang/blog.rust-lang.org#1319). Bootstrap change history: this PR changes the default of a config option on `x86_64-unknown-linux-gnu`. It's, however, not expected to cause issues, or require any changes to existing configurations. It's a big enough change that people should at least know about it, in case it causes unexpected problems. If that happens, set `rust.lld = false` in your `config.toml` (and open an issue).
Mark-Simulacrum
approved these changes
May 17, 2024
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this pull request
May 24, 2024
Enable `rust-lld` on nightly `x86_64-unknown-linux-gnu` We believe we have done virtually all the internal work and tests we could to prepare for using `lld` as the default linker (at least on Linux). We're IMHO at a point where we'd need to expand testing and coverage in order to make progress on this effort. Therefore, for further testing and gathering real-world feedback, unexpected issues and use-cases, this PR enables `rust-lld` as the default linker: - on nightly only (and dev channel) - on `x86_64-unknown-linux-gnu` only - when not using an external LLVM (except `download-ci-llvm`), so that distros are not impacted as described in more detail in this [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Enabling.20.60rust-lld.60.20on.20nightly.20.60x86_64-unknown-linux-gnu.60/near/433709343). In case any issues happen to users, as e.g. lld is not bug-for-bug compatible with GNU ld, it's easy to disable with `-Zlinker-features=-lld` to revert to using the system's default linker. --- I don't know who should review this kind of things, as it's somewhat of a crosscutting effort. Compiler contributor, compiler performance WG and infra member sounds perfect, so r? `@Mark-Simulacrum.` The last crater run encountered a low number (44) of mainly avoidable issues, like small incompatibilities, user errors, and a difference between the two linkers about which default to use with `--gc-sections`. [Here's the triage report](https://hackmd.io/OAJxlxc6Te6YUot9ftYSKQ?view), categorizing the issues, with some analyses and workarounds. I'd appreciate another set of eyes looking at these results. The changes in this PR have been test-driven for CI changes, try builds with tests enabled, rustc-perf with bootstrapping, in PR #113382. For infra, about the CI change: this PR forces `rust.lld` to false on vanilla LLVM builders, just to make sure we have coverage without `rust-lld`. Though to be clear, just using an external LLVM is already enough to keep `rust.lld` to false, in turn reverting everything to using the system's default linker. cc `@rust-lang/bootstrap` for the bootstrap and config change cc `@petrochenkov` for the small compiler change cc `@rust-lang/wg-compiler-performance` The blog post announcing the change, that we expect to merge around the same time as we merge this PR, is open [on the blog repo](rust-lang/blog.rust-lang.org#1319). Bootstrap change history: this PR changes the default of a config option on `x86_64-unknown-linux-gnu`. It's, however, not expected to cause issues, or require any changes to existing configurations. It's a big enough change that people should at least know about it, in case it causes unexpected problems. If that happens, set `rust.lld = false` in your `config.toml` (and open an issue).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is the companion announcement post needed for rust-lang/rust#124129, about switching the default linker on linux nightlies to
rust-lld, our "self-containedlld".The publication date is just a random day next week, just to leave time for comments here and on the rustc PR. I'm also not sure if this should be published on Inside Rust (like I've done here), or the main blog.
cc @Mark-Simulacrum and @rust-lang/wg-compiler-performance in particular