-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
check lld version to choose correct option to disable multi-threading in tests #102101
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
rustbot
added
the
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
label
Sep 21, 2022
rust-highfive
added
the
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
label
Sep 21, 2022
@rustbot author |
rustbot
added
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Sep 21, 2022
belovdv
force-pushed
the
new-check-lld-version
branch
from
September 21, 2022 15:12
6d742a4
to
9ac8ce5
Compare
belovdv
changed the title
check lld version
check lld version to choose correct option to disable multi-threading in tests
Sep 21, 2022
belovdv
force-pushed
the
new-check-lld-version
branch
from
September 26, 2022 08:44
9ac8ce5
to
6e4bfc2
Compare
@rustbot ready |
rustbot
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Sep 26, 2022
petrochenkov
reviewed
Oct 6, 2022
petrochenkov
added
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Oct 6, 2022
belovdv
force-pushed
the
new-check-lld-version
branch
from
October 19, 2022 12:27
6e4bfc2
to
967b4b1
Compare
@rustbot ready |
rustbot
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Oct 19, 2022
petrochenkov
added
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Oct 19, 2022
belovdv
force-pushed
the
new-check-lld-version
branch
from
October 19, 2022 14:48
6d7a1f0
to
3446cc3
Compare
@rustbot ready |
rustbot
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Oct 19, 2022
petrochenkov
added
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Oct 19, 2022
belovdv
force-pushed
the
new-check-lld-version
branch
from
October 24, 2022 08:24
856ae4a
to
5b904cc
Compare
belovdv
force-pushed
the
new-check-lld-version
branch
from
October 26, 2022 08:18
fe50ec3
to
0c4a01a
Compare
@rustbot ready |
rustbot
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Oct 26, 2022
@bors r+ |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Oct 26, 2022
compiler-errors
added a commit
to compiler-errors/rust
that referenced
this pull request
Oct 26, 2022
…etrochenkov check lld version to choose correct option to disable multi-threading in tests Testing compiler with 'use-lld = true' may be incorrect with old lld. Flag, disabling multi-threading, should consider lld version. r? `@petrochenkov`
notriddle
added a commit
to notriddle/rust
that referenced
this pull request
Oct 30, 2022
…etrochenkov check lld version to choose correct option to disable multi-threading in tests Testing compiler with 'use-lld = true' may be incorrect with old lld. Flag, disabling multi-threading, should consider lld version. r? `@petrochenkov`
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 31, 2022
Rollup of 8 pull requests Successful merges: - rust-lang#97971 (Enable varargs support for calling conventions other than C or cdecl ) - rust-lang#101428 (Add mir building test directory) - rust-lang#101944 (rustdoc: clean up `#toggle-all-docs`) - rust-lang#102101 (check lld version to choose correct option to disable multi-threading in tests) - rust-lang#102689 (Add a tier 3 target for the Sony PlayStation 1) - rust-lang#103746 (rustdoc: add support for incoherent impls on structs and traits) - rust-lang#103758 (Add regression test for reexports in search results) - rust-lang#103764 (All verbosity checks in `PrettyPrinter` now go through `PrettyPrinter::should_print_verbose`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This was referenced Sep 27, 2023
Kobzol
added a commit
to Kobzol/rust
that referenced
this pull request
Sep 29, 2023
This flag wasn't used for anything after rust-lang#102101.
Kobzol
added a commit
to Kobzol/rust
that referenced
this pull request
Oct 2, 2023
This flag wasn't used for anything after rust-lang#102101.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 9, 2023
…arsan68,petrochenkov Generalize LLD usage in bootstrap The current usage of using LLD (`rust.use-lld = true`) in bootstrap is a bit messy. What it claimed: > Indicates whether LLD will be used to link Rust crates during bootstrap on > supported platforms. The LLD from the bootstrap distribution will be used > and not the LLD compiled during the bootstrap. What it did: 1) On MSVC, it did indeed use the snapshot compiler's `rust-lld`, but at the same time it was invoking a global `lld` binary (since rust-lang#102101), therefore it wouldn't work if `lld` wasn't available. 2) On other targets, it was just straight up using a global `lld` linker. If it wasn't available, it would fail. This PR (hopefully) cleans up handling of LLD in bootstrap. It introduces a new enum called `LldMode`, which explicitly distinguishes between no LLD, external LLD and self-contained LLD. Since it's non-trivial to provide a custom path to LLD, if an external `lld` is used, the linker binary has to be named exactly `lld` and it has to be available in PATH. In addition, this PR also dog-foods [MCP510](rust-lang/compiler-team#510) in bootstrap. To keep backwards compatibility somewhat, I kept the original `use-lld` flag and mapped the `true` value to `"external"`, which is how it behaved before on Linux and other non-MSVC targets. Having the option to use an external `lld` on Linux should come in handy for testing on CI once MCP510 sets the default linker on Linux to `lld`. Note that thanks to MCP510, currently "self-contained" means that `lld` is used from the stage N-1 compiler (before, we always used `lld` from the snapshot/stage0 compiler). Best reviewed commit by commit. CC `@petrochenkov`
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 10, 2023
…arsan68,petrochenkov Generalize LLD usage in bootstrap The current usage of using LLD (`rust.use-lld = true`) in bootstrap is a bit messy. What it claimed: > Indicates whether LLD will be used to link Rust crates during bootstrap on > supported platforms. The LLD from the bootstrap distribution will be used > and not the LLD compiled during the bootstrap. What it did: 1) On MSVC, it did indeed use the snapshot compiler's `rust-lld`, but at the same time it was invoking a global `lld` binary (since rust-lang#102101), therefore it wouldn't work if `lld` wasn't available. 2) On other targets, it was just straight up using a global `lld` linker. If it wasn't available, it would fail. This PR (hopefully) cleans up handling of LLD in bootstrap. It introduces a new enum called `LldMode`, which explicitly distinguishes between no LLD, external LLD and self-contained LLD. Since it's non-trivial to provide a custom path to LLD, if an external `lld` is used, the linker binary has to be named exactly `lld` and it has to be available in PATH. In addition, this PR also dog-foods [MCP510](rust-lang/compiler-team#510) in bootstrap. To keep backwards compatibility somewhat, I kept the original `use-lld` flag and mapped the `true` value to `"external"`, which is how it behaved before on Linux and other non-MSVC targets. Having the option to use an external `lld` on Linux should come in handy for testing on CI once MCP510 sets the default linker on Linux to `lld`. Note that thanks to MCP510, currently "self-contained" means that `lld` is used from the stage N-1 compiler (before, we always used `lld` from the snapshot/stage0 compiler). Best reviewed commit by commit. CC `@petrochenkov`
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 10, 2023
…arsan68,petrochenkov Generalize LLD usage in bootstrap The current usage of using LLD (`rust.use-lld = true`) in bootstrap is a bit messy. What it claimed: > Indicates whether LLD will be used to link Rust crates during bootstrap on > supported platforms. The LLD from the bootstrap distribution will be used > and not the LLD compiled during the bootstrap. What it did: 1) On MSVC, it did indeed use the snapshot compiler's `rust-lld`, but at the same time it was invoking a global `lld` binary (since rust-lang#102101), therefore it wouldn't work if `lld` wasn't available. 2) On other targets, it was just straight up using a global `lld` linker. If it wasn't available, it would fail. This PR (hopefully) cleans up handling of LLD in bootstrap. It introduces a new enum called `LldMode`, which explicitly distinguishes between no LLD, external LLD and self-contained LLD. Since it's non-trivial to provide a custom path to LLD, if an external `lld` is used, the linker binary has to be named exactly `lld` and it has to be available in PATH. In addition, this PR also dog-foods [MCP510](rust-lang/compiler-team#510) in bootstrap. To keep backwards compatibility somewhat, I kept the original `use-lld` flag and mapped the `true` value to `"external"`, which is how it behaved before on Linux and other non-MSVC targets. Having the option to use an external `lld` on Linux should come in handy for testing on CI once MCP510 sets the default linker on Linux to `lld`. Note that thanks to MCP510, currently "self-contained" means that `lld` is used from the stage N-1 compiler (before, we always used `lld` from the snapshot/stage0 compiler). Best reviewed commit by commit. CC `@petrochenkov`
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Dec 12, 2023
…etrochenkov Generalize LLD usage in bootstrap The current usage of using LLD (`rust.use-lld = true`) in bootstrap is a bit messy. What it claimed: > Indicates whether LLD will be used to link Rust crates during bootstrap on > supported platforms. The LLD from the bootstrap distribution will be used > and not the LLD compiled during the bootstrap. What it did: 1) On MSVC, it did indeed use the snapshot compiler's `rust-lld`, but at the same time it was invoking a global `lld` binary (since rust-lang/rust#102101), therefore it wouldn't work if `lld` wasn't available. 2) On other targets, it was just straight up using a global `lld` linker. If it wasn't available, it would fail. This PR (hopefully) cleans up handling of LLD in bootstrap. It introduces a new enum called `LldMode`, which explicitly distinguishes between no LLD, external LLD and self-contained LLD. Since it's non-trivial to provide a custom path to LLD, if an external `lld` is used, the linker binary has to be named exactly `lld` and it has to be available in PATH. In addition, this PR also dog-foods [MCP510](rust-lang/compiler-team#510) in bootstrap. To keep backwards compatibility somewhat, I kept the original `use-lld` flag and mapped the `true` value to `"external"`, which is how it behaved before on Linux and other non-MSVC targets. Having the option to use an external `lld` on Linux should come in handy for testing on CI once MCP510 sets the default linker on Linux to `lld`. Note that thanks to MCP510, currently "self-contained" means that `lld` is used from the stage N-1 compiler (before, we always used `lld` from the snapshot/stage0 compiler). Best reviewed commit by commit. CC `@petrochenkov`
lnicola
pushed a commit
to lnicola/rust-analyzer
that referenced
this pull request
Apr 7, 2024
…etrochenkov Generalize LLD usage in bootstrap The current usage of using LLD (`rust.use-lld = true`) in bootstrap is a bit messy. What it claimed: > Indicates whether LLD will be used to link Rust crates during bootstrap on > supported platforms. The LLD from the bootstrap distribution will be used > and not the LLD compiled during the bootstrap. What it did: 1) On MSVC, it did indeed use the snapshot compiler's `rust-lld`, but at the same time it was invoking a global `lld` binary (since rust-lang/rust#102101), therefore it wouldn't work if `lld` wasn't available. 2) On other targets, it was just straight up using a global `lld` linker. If it wasn't available, it would fail. This PR (hopefully) cleans up handling of LLD in bootstrap. It introduces a new enum called `LldMode`, which explicitly distinguishes between no LLD, external LLD and self-contained LLD. Since it's non-trivial to provide a custom path to LLD, if an external `lld` is used, the linker binary has to be named exactly `lld` and it has to be available in PATH. In addition, this PR also dog-foods [MCP510](rust-lang/compiler-team#510) in bootstrap. To keep backwards compatibility somewhat, I kept the original `use-lld` flag and mapped the `true` value to `"external"`, which is how it behaved before on Linux and other non-MSVC targets. Having the option to use an external `lld` on Linux should come in handy for testing on CI once MCP510 sets the default linker on Linux to `lld`. Note that thanks to MCP510, currently "self-contained" means that `lld` is used from the stage N-1 compiler (before, we always used `lld` from the snapshot/stage0 compiler). Best reviewed commit by commit. CC `@petrochenkov`
RalfJung
pushed a commit
to RalfJung/rust-analyzer
that referenced
this pull request
Apr 27, 2024
…etrochenkov Generalize LLD usage in bootstrap The current usage of using LLD (`rust.use-lld = true`) in bootstrap is a bit messy. What it claimed: > Indicates whether LLD will be used to link Rust crates during bootstrap on > supported platforms. The LLD from the bootstrap distribution will be used > and not the LLD compiled during the bootstrap. What it did: 1) On MSVC, it did indeed use the snapshot compiler's `rust-lld`, but at the same time it was invoking a global `lld` binary (since rust-lang/rust#102101), therefore it wouldn't work if `lld` wasn't available. 2) On other targets, it was just straight up using a global `lld` linker. If it wasn't available, it would fail. This PR (hopefully) cleans up handling of LLD in bootstrap. It introduces a new enum called `LldMode`, which explicitly distinguishes between no LLD, external LLD and self-contained LLD. Since it's non-trivial to provide a custom path to LLD, if an external `lld` is used, the linker binary has to be named exactly `lld` and it has to be available in PATH. In addition, this PR also dog-foods [MCP510](rust-lang/compiler-team#510) in bootstrap. To keep backwards compatibility somewhat, I kept the original `use-lld` flag and mapped the `true` value to `"external"`, which is how it behaved before on Linux and other non-MSVC targets. Having the option to use an external `lld` on Linux should come in handy for testing on CI once MCP510 sets the default linker on Linux to `lld`. Note that thanks to MCP510, currently "self-contained" means that `lld` is used from the stage N-1 compiler (before, we always used `lld` from the snapshot/stage0 compiler). Best reviewed commit by commit. CC `@petrochenkov`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
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.
Testing compiler with 'use-lld = true' may be incorrect with old lld.
Flag, disabling multi-threading, should consider lld version.
r? @petrochenkov