create symlink for legacy rustfmt path
Fixes#107547 .
Main change is in the `download.rs` file. Created a symlink for the legacy rustfmt path to the new rustfmt path. Other file changes are simply as a result of porting over the symlink_file function from the Build struct to the config Struct
Set `rust-analyzer.check.invocationLocation` to `root`
Add
```json
"rust-analyzer.check.invocationLocation": "root",
"rust-analyzer.check.invocationStrategy": "once",
```
to the bundled VS code config. This prevents an error with r-a invoking `python3 x.py` in `src/bootstrap` where `x.py` does not exist.
r? ``@jyn514``
x.py fails all downloads that use a tempdir with snap curl #107722
Have used the open() library from python to capture the binary output of the curl command and write it to a file using stdout of the subprocess. Added a single-line comment mentioning the redirect operator.
Previously, the pre-commit hook which runs `x test tidy` could pass only to have CI fail within the first 30 seconds.
This adds about 30 seconds to `test tidy` (for an initial run, much less after the tool is built the first time)
in exchange for catching errors in `.github/workflows/ci.yml` before they're pushed.
consolidate bootstrap docs
With this diff, I tried to consolidate bootstrap documentations and remove the duplicated informations.
Coupled with https://github.com/rust-lang/rustc-dev-guide/pull/1563Resolves#90686
Signed-off-by: ozkanonur <work@onurozkan.dev>
Add `rust.lto=off` to bootstrap and set as compiler/library default
Closes#107202
The issue mentions `embed-bitcode=on`, but here c8e6a9e8b6/src/bootstrap/compile.rs (L379-L381)
it appears that this is always set for std stage 1+, so I'm unsure if changes are needed here.
`@rustbot` label +A-bootstrap
Small bootstrap improvements
- i/o-less check for `xz` availability
- cache result of NixOS detection
- load correct `bootstrap` module even when a package of that name is installed
- no `-W semicolon_in_expressions_from_macros` – it is warn-by-default
- one type per variable (making dynamic typing less confusing)
- integrate python-side `--help` flag into the argument parser (makes `-hv` work as a short form of `--help --verbose`)
I even checked that it works with Python 2.
Bump bootstrap compiler to 1.68
This also changes our stage0.json to include the rustc component for the rustfmt pinned nightly toolchain, which is currently necessary due to rustfmt dynamically linking to that toolchain's librustc_driver and libstd.
r? `@pietroalbini`
bootstrap: cleanup the list of extra check cfgs
This PR performs some cleanups on the `EXTRA_CHECK_CFGS` list in bootstrap.
- `target_os=watchos`: no longer relevant because there are now proper targets `*-apple-watchos`
- `target_arch=nvptx64`: target `nvptx64-nvidia-cuda` makes it useless
- `target_arch=le32`: target was removed (https://github.com/rust-lang/rust/pull/45041)
- `release`: was removed from rustfmt (https://github.com/rust-lang/rustfmt/pull/5375 and https://github.com/rust-lang/rustfmt/pull/5449)
- `dont_compile_me`: was removed from stdarch (https://github.com/rust-lang/stdarch/pull/1308)
Also made some external cfg exception mode clear and only activated for rustc and rustc tools (as to not have the Standard Library unintentionally depend on them).
Add option to include private items in library docs
I need to perform some one-off analysis on libcore, and I wanted to use the unstable JSON rustdoc output to easily do it. Unfortunately, there is currently no way to include unstable items in the library docs. This PR adds support for that, with the off-by-default `build.library-docs-private-items` setting.
Revisit fix_is_ci_llvm_available logic
Fixes#107225
Now `supported_platforms` has a knowledge whether llvm asserts artifacts are available for particular host triple.
``@jyn514`` ``@albertlarsan68`` PTAL
Print PID holding bootstrap build lock on Linux
Partially address #107077
Parse `/proc/locks` to find the PID of the process which created the build directory lock
Make stage2 rustdoc and proc-macro-srv disableable in x.py install
Rustdoc will build if `[build] tools = ["rustdoc"]` is set, and rust-analyzer-proc-macro-srv will build if `[build] tools = ["rust-analyzer"]` is set.
On my machine skipping these tools speeds up `x.py install` from 7m15s to 6m08s (0m43s for rustdoc and 0m24s for rust-analyzer-proc-macro-srv). This is a significant speedup, since I never use rust-analyzer-proc-macro-srv, and I practically never need to use a custom build of rustdoc.
Enable sanitizers for s390x-linux
Include sanitizers supported by LLVM on s390x (asan, lsan, msan, tsan) in the target definition, as well as in the compiletest supported list.
Build sanitizer runtime for the target. Enable sanitizers in the CI.
Re-enable building rust-analyzer on riscv64
It was disabled in #75103 due to an LLVM bug, but followup comments have
confirmed that it builds fine on Fedora with LLVM 15.
r? ```@Mark-Simulacrum```
cc ```@matklad``` ```@davidlt```
Include sanitizers supported by LLVM on s390x (asan, lsan, msan, tsan)
in the target definition, as well as in the compiletest supported list.
Build sanitizer runtime for the target. Enable sanitizers in the CI.
Update mdbook
This updates mdbook from 0.4.21 to 0.4.25. The list of changes is [here](https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0425). The only user-visible changes are some changes around the theme picker, and change to the copy-to-clipboard ignoring hidden lines.
Internally there were some dependency updates and small fixes.
This also updates `clap` from 4.0.15 to 4.0.32 whose changelog is [here](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md#4032---2022-12-22). This impacts tools like cargo. I don't see anything particularly noteworthy there, though there are some small user-visible changes.
Unfortunately this required adding a hack for building `rustix` with a bootstrap tool. The comment explains why. I am unable to think of some other workaround (or even a cleaner way to set the rustflag). Ideas are welcome if you can think of alternatives. I'm struggling to even think of a long-term solution, other than asking projects not to do auto-nightly feature detection.
One medium-term solution is to avoid the clap dependency for the mdbook library (which is how rustix gets pulled in). That is one of my goals for the 0.5 release of mdbook, but that probably won't happen until later this year. It would also require dropping clap from `rustbook` and using some other means to parse arguments (there's only two options, so it can probably be done manually).
