CI: enable arbitrary try builds, take two
Fixed version of https://github.com/rust-lang/rust/pull/124631, which hopefully won't completely break our CI this time 🤦♂️ Sorry once again. Only the last commit is new.
r? `@pietroalbini`
Ignore empty RUSTC_WRAPPER in bootstrap
This change ignores the RUSTC_WRAPPER_REAL environment variable if it's set to the empty string. This matches cargo behaviour and allows users to easily shadow a globally set RUSTC_WRAPPER (which they might have set for non-rustc projects).
I hit this because I have RUSTC_WRAPPER set to `sccache` in my fish universal env vars, and I can only shadow those locally with an empty string, I can't unset it entirely.
Simplify `use crate::rustc_foo::bar` occurrences.
They can just be written as `use rustc_foo::bar`, which is far more standard. (I didn't even know that a `crate::` prefix was valid.)
r? ``@eholk``
Remove braces when fixing a nested use tree into a single item
[Back in 2019](https://github.com/rust-lang/rust/pull/56645) I added rustfix support for the `unused_imports` lint, to automatically remove them when running `cargo fix`. For the most part this worked great, but when removing all but one childs of a nested use tree it turned `use foo::{Unused, Used}` into `use foo::{Used}`. This is slightly annoying, because it then requires you to run `rustfmt` to get `use foo::Used`.
This PR automatically removes braces and the surrouding whitespace when all but one child of a nested use tree are unused. To get it done I had to add the span of the nested use tree to the AST, and refactor a bit the code I wrote back then.
A thing I noticed is, there doesn't seem to be any `//@ run-rustfix` test for fixing the `unused_imports` lint. I created a test in `tests/suggestions` (is that the right directory?) that for now tests just what I added in the PR. I can followup in a separate PR to add more tests for fixing `unused_lints`.
This PR is best reviewed commit-by-commit.
This change ignores the RUSTC_WRAPPER_REAL environment variable if it's
set to the empty string. This matches cargo behaviour and allows users
to easily shadow a globally set RUSTC_WRAPPER (which they might have set
for non-rustc projects).
rustdoc: use stability, instead of features, to decide what to show
Fixes#124635
To decide if internal items should be inlined in a doc page, check if the crate is itself internal, rather than if it has the rustc_private feature flag. The standard library uses internal items, but is not itself internal and should not show internal items on its docs pages.
Fuchsia test runner: fixup script
This commit fixes several issues in the fuchsia-test-runner.py script:
1. Migrate from `pm` to `ffx` for package management, as `pm` is now deprecated. Furthermore, the `pm` calls used in this script no longer work at Fuchsia's HEAD. This is the largest change in this commit, and impacts all steps around repository management (creation and registration of the repo, as well as package publishing).
2. Allow for `libtest` to be either statically or dynamically linked. The script assumed it was dynamically linked, but the current Rust behavior at HEAD is to statically link it.
3. Minor cleanup to use `ffx --machine json` rather than string parsing.
4. Minor cleanup to the docs around the script.
To decide if internal items should be inlined in a doc page,
check if the crate is itself internal, rather than if it has
the rustc_private feature flag. The standard library uses
internal items, but is not itself internal and should not show
internal items on its docs pages.
This commit fixes several issues in the fuchsia-test-runner.py script:
1. Migrate from `pm` to `ffx` for package management, as `pm` is now
deprecated. Furthermore, the `pm` calls used in this script no longer
work at Fuchsia's HEAD. This is the largest change in this commit, and
impacts all steps around repository management (creation and
registration of the repo, as well as package publishing).
2. Allow for `libtest` to be either statically or dynamically linked.
The script assumed it was dynamically linked, but the current Rust
behavior at HEAD is to statically link it.
3. Minor cleanup to use `ffx --machine json` rather than string parsing.
4. Minor cleanup to the docs around the script.
rustdoc: dedup search form HTML
This change constructs the search form HTML using JavaScript, instead of plain HTML. It uses a custom element because
- the [parser]'s insert algorithm runs the connected callback synchronously, so we won't get layout jank
- it requires very little HTML, so it's a real win in size
[parser]: https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token
This shrinks the standard library by about 60MiB, by my test.
There should be no visible changes. Just use less disk space.
Implement lldb formatter for "clang encoded" enums (LLDB 18.1+) (V3)
This is a redo of PR (#124458) which was approved previously but force-pushed out. Then a V2 (#124745) failed `debuginfo\msvc-pretty-enums.rs` test during merge.
I've fixed the test and checked it to pass on Windows with `.\x.ps1 test .\tests\debuginfo\msvc-pretty-enums.rs`
Below is the original summary:
## Summary:
fixes#79530
I landed a fix last year to enable `DW_TAG_variant_part` encoding in LLDBs (https://reviews.llvm.org/D149213). This PR is a corresponding fix in synthetic formatters to decode that information.
This is in no way perfect implementation but at least it improves the status quo. But most types of enums will be visible and debuggable in some way.
I've also updated most of the existing tests that touch enums and re-enabled test cases based on LLDB for enums.
## Test Plan:
ran tests `./x test tests/debuginfo/`. Also tested manually in LLDB CLI and LLDB VSCode
## Other Thoughs:
A better approach would probably be adopting [formatters from codelldb](https://github.com/vadimcn/codelldb/blob/master/formatters/rust.py). There is some neat hack that hooks up summary provider via synthetic provider which can ultimately fix more display issues for Rust types and enums too. But getting it to work well might take more time that I have right now.
Update cc crate for bootstrap to v1.0.97
Reason:
In order to build the Windows version of the Rust toolchain for the Android platform, the following patch to the cc is crate is required to avoid incorrectly determining that we are building with the Android NDK: 57853c4bf8
This patch is present in version 1.0.80 and newer versions of the cc crate. The rustc source distribution currently has 3 different versions of cc in the vendor directory, only one of which has the necessary fix.
We (the Android Rust toolchain) are currently maintaining local patches to upgrade the cc crate dependency versions, which we would like to upstream.
Furthermore, beyond the specific reason, the cc crate in bootstrap is currently pinned at an old version due to problems in the past when trying to update it. It is worthwhile to figure out and resolve these problems so we can keep the dependency up-to-date.
Other fixes:
As of cc v1.0.78, object files are prefixed with a 16-character hash.
Update src/bootstrap/src/core/build_steps/llvm.rs to account for this to
avoid failures when building libunwind and libcrt. Note that while the hash
prefix was introduced in v1.0.78, in order to determine the names of the
object files without scanning the directory, we rely on the compile_intermediates
method, which was introduced in cc v1.0.86
As of cc v1.0.86, compilation on MacOS uses the -mmacosx-version-min flag.
A long-standing bug in the CMake rules for compiler-rt causes compilation
to fail when this flag is specified. So we add a workaround to suppress this
flag.
Updating to cc v1.0.91 and newer requires fixes to bootstrap unit tests.
The unit tests use targets named "A", "B", etc., which fail a validation
check introduced in 1.0.91 of the cc crate.
As of cc v1.0.74, the SDKROOT environment variable is used on Darwin if present,
regardless of whether it is for the correct platform or not. This is fixed in cc v1.0.97.
Reason:
In order to build the Windows version of the Rust toolchain for the Android platform, the following patch to the cc is crate is required to avoid incorrectly determining that we are building with the Android NDK: 57853c4bf8
This patch is present in version 1.0.80 and newer versions of the cc crate. The rustc source distribution currently has 3 different versions of cc in the vendor directory, only one of which has the necessary fix.
We (the Android Rust toolchain) are currently maintaining local patches to upgrade the cc crate dependency versions, which we would like to upstream.
Furthermore, beyond the specific reason, the cc crate in bootstrap is currently pinned at an old version due to problems in the past when trying to update it. It is worthwhile to figure out and resolve these problems so we can keep the dependency up-to-date.
Other fixes:
As of cc v1.0.78, object files are prefixed with a 16-character hash.
Update src/bootstrap/src/core/build_steps/llvm.rs to account for this to
avoid failures when building libunwind and libcrt. Note that while the hash
prefix was introduced in v1.0.78, in order to determine the names of the
object files without scanning the directory, we rely on the compile_intermediates
method, which was introduced in cc v1.0.86
As of cc v1.0.86, compilation on MacOS uses the -mmacosx-version-min flag.
A long-standing bug in the CMake rules for compiler-rt causes compilation
to fail when this flag is specified. So we add a workaround to suppress this
flag.
Updating to cc v1.0.91 and newer requires fixes to bootstrap unit tests.
The unit tests use targets named "A", "B", etc., which fail a validation
check introduced in 1.0.91 of the cc crate.
Make check-cfg docs more user-friendly
This PR improves the `--check-cfg` to make them more user-friendly by:
- explaining the purpose of the feature
- removing the "form" jargon
- making it (bit) less formal and more "friendly"
- making the doc less cluttered
- and by fixing (the width and flags) of the examples
`@rustbot` label +F-check-cfg
Migrate `run-make/rustdoc-error-lines` to new `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
There was a weird naming inconsistency with `input`/`output`. A few tests write `.arg("-o").arg(path)` and the `output` method was actually the command output. So instead, I renamed the original `output` into `command_output` so that I could create the `output` method with the expected effect (and updated the tests to use it too).
EDIT: The first two commits come from https://github.com/rust-lang/rust/pull/124711. Some weird things happened recently pparently. ^^'
r? `@jieyouxu`
Summary:
I landed a fix last year to enable `DW_TAG_variant_part` encoding in LLDBs (https://reviews.llvm.org/D149213). This PR is a corresponding fix in synthetic formatters to decode that information.
This is in no way perfect implementation but at least it improves the status quo. But most types of enums will be visible and debuggable in some way.
I've also updated most of the existing tests that touch enums and re-enabled test cases based on LLDB for enums.
Test Plan:
ran tests `./x test tests/debuginfo/`. Also tested manually in LLDB CLI and LLDB VSCode
Other Thoughs
A better approach would probably be adopting [formatters from codelldb](https://github.com/vadimcn/codelldb/blob/master/formatters/rust.py). There is some neat hack that hooks up summary provider via synthetic provider which can ultimately fix more display issues for Rust types and enums too. But getting it to work well might take more time that I have right now.
This change constructs the search form HTML using JavaScript, instead of plain HTML. It uses a custom element because
- the [parser]'s insert algorithm runs the connected callback synchronously, so we won't get layout jank
- it requires very little HTML, so it's a real win in size
[parser]: https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token
This shrinks the standard library by about 60MiB, by my test.
Fix bootstrap panic when build from tarball
Got this error when build from beta tarball (2024-05-03)
regression of 6f4f39a8d5
panic info:
```
thread 'main' panicked at src/core/builder.rs:583:25:
`should_run.paths` should correspond to real on-disk paths - use `alias` if there is no relevant path: src/llvm-project/compiler-rt/lib/crt
stack backtrace:
0: rust_begin_unwind
1: core::panicking::panic_fmt
2: bootstrap::core::builder::ShouldRun::paths::{{closure}}
at ./src/bootstrap/src/core/builder.rs:583:25
3: core::iter::adapters::map::map_fold::{{closure}}
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/adapters/map.rs:89:28
4: <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::fold
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/slice/iter/macros.rs:232:27
5: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/adapters/map.rs:129:9
6: core::iter::traits::iterator::Iterator::for_each
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:817:9
7: alloc::vec::Vec<T,A>::extend_trusted
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/mod.rs:3020:17
8: <alloc::vec::Vec<T,A> as alloc::vec::spec_extend::SpecExtend<T,I>>::spec_extend
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_extend.rs:26:9
9: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_from_iter_nested.rs:62:9
10: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_from_iter.rs:33:9
11: <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/mod.rs:2894:9
12: core::iter::traits::iterator::Iterator::collect
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:2003:9
13: <alloc::collections::btree::set::BTreeSet<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/collections/btree/set.rs:1191:34
14: core::iter::traits::iterator::Iterator::collect
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:2003:9
15: bootstrap::core::builder::ShouldRun::paths
at ./src/bootstrap/src/core/builder.rs:578:13
16: bootstrap::core::builder::ShouldRun::path
at ./src/bootstrap/src/core/builder.rs:562:9
17: <bootstrap::core::build_steps::llvm::CrtBeginEnd as bootstrap::core::builder::Step>::should_run
at ./src/bootstrap/src/core/build_steps/llvm.rs:1174:9
18: bootstrap::core::builder::StepDescription::run::{{closure}}
at ./src/bootstrap/src/core/builder.rs:416:25
19: core::iter::adapters::map::map_fold::{{closure}}
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/adapters/map.rs:89:28
20: <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::fold
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/slice/iter/macros.rs:232:27
21: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/adapters/map.rs:129:9
22: core::iter::traits::iterator::Iterator::for_each
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:817:9
23: alloc::vec::Vec<T,A>::extend_trusted
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/mod.rs:3020:17
24: <alloc::vec::Vec<T,A> as alloc::vec::spec_extend::SpecExtend<T,I>>::spec_extend
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_extend.rs:26:9
25: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_from_iter_nested.rs:62:9
26: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_from_iter.rs:33:9
27: <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/mod.rs:2894:9
28: core::iter::traits::iterator::Iterator::collect
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:2003:9
29: bootstrap::core::builder::StepDescription::run
at ./src/bootstrap/src/core/builder.rs:414:27
30: bootstrap::core::builder::Builder::run_step_descriptions
at ./src/bootstrap/src/core/builder.rs:1047:9
31: bootstrap::core::builder::Builder::execute_cli
at ./src/bootstrap/src/core/builder.rs:1028:9
32: bootstrap::Build::build
at ./src/bootstrap/src/lib.rs:683:17
33: bootstrap::main
at ./src/bootstrap/src/bin/main.rs:79:5
34: core::ops::function::FnOnce::call_once
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:250:5
```
