bootstrap: Allow `./x check compiletest`
Did you know that bootstrap didn't support `./x check compiletest`? Well, now it does!
Manually add `"compiletest"` to your `rust-analyzer.check.overrideCommand` check command to get error/warning integration when modifying compiletest.
bootstrap: drop warning for top-level test suite path check due to false positives
The current top-level test suite directory does not exist warning logic doesn't quite handle the more exotic path suffix matches that test filters seem to accept (e.g. `library/test` can be matched with `--exclude test`), so avoid warning on non-existent top-level test suites for now. To avoid false positives, we probably need to query test `Step`s for their `should_run(exclude_filter)` logic.
This retains the fix for the Windows path handling (unlike #134843).
r? `@onur-ozkan`
This doesn't quite handle the more exotic path suffix matches that test
filters seem to accept (e.g. `library/test` can be matched with
`--exclude test`), so avoid warning on non-existent top-level test
suites for now. A proper fix will need to possibly query test `Step`s
for their exclude logic.
Generate shell completions for x as well
It would be nice to be have shell completions for both `./x` and `x` (installed with `cargo install --path src/tools/x`) instead of just `x.py`. This pr generates the corresponding completions for each shell in a similar way to `x.py` but under `x.<shell>` instead.
reduce compiler `Assemble` complexity
`compile::Assemble` is already complicated by its nature (as it handles core internals like recursive building logic, etc.) and also handles half of `LldWrapper` tool logic for no good reason since it should be done in the build step directly.
This change moves it there to reduce complexity of `compile::Assemble` logic.
`compile::Assemble` is already complicated by its nature (as it handles core
internals like recursive building logic, etc.) and also handles half of `LldWrapper`
tool logic for no good reason since it should be done in the build step directly.
This change moves it there to reduce complexity of `compile::Assemble` logic.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Fix `x build --stage 1 std` when using cg_cranelift as the default backend
Before, cg_cranelift would ICE when trying to lower f16 and f128. The library/ crates had all the infrastructure to omit using them, it just wasn't hooked up to bootstrap.
r? `````@bjorn3`````
Before, cg_cranelift would ICE when trying to lower f16 and f128. The
library/ crates had all the infrastructure to omit using them, it just
wasn't hooked up to bootstrap.
bootstrap: use specific-purpose ui test path for `test_valid` self-test
I wanted to move some ui tests around in #134418, which broke `test_valid` since it was referencing two non-specific-purpose ui tests. This PR instead adds two dummy tests under `tests/ui/bootstrap/self-test/`, for that purpose specifically.
r? bootstrap
Promote powerpc64le-unknown-linux-musl to tier 2 with host tools
MCP: https://github.com/rust-lang/compiler-team/issues/803
I'm using crosstool-ng for building a toolchain because GCC 9 from `musl-toolchain.sh` has float ABI issues (?) and can't compile LLVM, and writing a crosstool-ng config for a target feels less hacky than yet another target specific shell script. I also defined a kernel version, since there wasn't one specified before. If a lower version is desired, just let me know. I also tried to match the rust configure args with the loongarch64 musl tier 2 target.
The resulting compiler works fine, built with `DEPLOY=1 ./src/ci/docker/run.sh dist-powerpc64le-linux` and tested on Alpine Linux in a VM and on a bare metal POWER8 machine:
```
qemu-ppc64le:/tmp/rust-nightly-powerpc64le-unknown-linux-musl$ ash install.sh
install: creating uninstall script at /usr/local/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'rust-std-powerpc64le-unknown-linux-musl'
install: installing component 'cargo'
install: installing component 'rustfmt-preview'
install: installing component 'rls-preview'
install: installing component 'rust-analyzer-preview'
install: installing component 'llvm-tools-preview'
install: installing component 'clippy-preview'
install: installing component 'miri-preview'
install: installing component 'rust-analysis-powerpc64le-unknown-linux-musl'
install: installing component 'llvm-bitcode-linker-preview'
install: WARNING: failed to run ldconfig. this may happen when not installing as root. run with --verbose to see the error
rust installed.
qemu-ppc64le:~$ echo 'fn main() { println!("hello world"); }' > test.rs
qemu-ppc64le:~$ rustc test.rs
qemu-ppc64le:~$ ./test
hello world
qemu-ppc64le:~$ file test
test: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (SYSV), statically linked, BuildID[sha1]=596ee6abf9add487ebc54fb71c2076fb6faea013, with debug_info, not stripped
```
try-job: dist-powerpc64le-linux
Rollup of 6 pull requests
Successful merges:
- #132150 (Fix powerpc64 big-endian FreeBSD ABI)
- #133942 (Clarify how to use `black_box()`)
- #134081 (Try to evaluate constants in legacy mangling)
- #134192 (Remove `Lexer`'s dependency on `Parser`.)
- #134208 (coverage: Tidy up creation of covmap and covfun records)
- #134211 (On Neutrino QNX, reduce the need to set archiver via environment variables)
r? `@ghost`
`@rustbot` modify labels: rollup
On Neutrino QNX, reduce the need to set archiver via environment variables
This adds support for automatically selecting the correct `ar` tool when compiling for Neutrino QNX.
Once https://github.com/rust-lang/cc-rs/pull/1319 is merged and a new cc version is integrated, all environment variables of the [Neutrino documentation](https://github.com/rust-lang/rust/blob/stable/src/doc/rustc/src/platform-support/nto-qnx.md) can be removed.
CC: ````````@jonathanpallant```````` ````````@japaric```````` ````````@gh-tr```````` ````````@AkhilTThomas````````
We don't need `NonNull::as_ptr` debuginfo
In order to stop pessimizing the use of local variables in core, skip debug info for MIR temporaries in tiny (single-BB) functions.
For functions as simple as this -- `Pin::new`, etc -- nobody every actually wants debuginfo for them in the first place. They're more like intrinsics than real functions, and stepping over them is good.
Revert "bootstrap: print{ln}! -> eprint{ln}! (take 2) #134040"
Unfortunately, #134040 is proving to have caused more output interleaving problems that are tricky to diagnose and fix, and I think we probably should leave these untouched as bootstrap and compiletest has a bunch of interconnecting parts, and the commands and tools that they exercise do not consistently use stderr/stdout either. This causes hard-to-diagnose output interleaving bugs, which unfortunately degrades contributor experience.
This PR reverts two PRs in order to cleanly revert #134040:
1. Revert #134123 which is a fix-forward after #134040.
2. Revert #134040 itself.
I don't regret the initial effort `@clubby789,` and thank you for making the attempts, but I think we need to refrain from touching too many of these at once because some of the interleaving are very non-obvious and we don't have test coverage for.
r? `@clubby789`
cc `@Zalathar`
allow `symbol_intern_string_literal` lint in test modules
Since #133545, `x check compiler --stage 1` no longer works because compiler test modules trigger `symbol_intern_string_literal` lint errors. Bootstrap shouldn't control when to ignore or enable this lint in the compiler tree (using `Kind != Test` was ineffective for obvious reasons).
Also, conditionally adding this rustflag invalidates the build cache between `x test` and other commands.
This PR removes the `Kind` check from bootstrap and handles it directly in the compiler tree in a more natural way.
bootstrap: Forward cargo JSON output to stdout, not stderr
This fixes the RA errors I've been seeing on proc-macros after the re-landing of #134040.
r? clubby789
Stop pessimizing the use of local variables in core by skipping debug info for MIR temporaries in tiny (single-BB) functions.
For functions as simple as this -- `Pin::new`, etc -- nobody every actually wants debuginfo for them in the first place. They're more like intrinsics than real functions, and stepping over them is good.
use vendor sources by default on dist tarballs
Tarball sources are distributed with vendor sources along with the `.cargo/config.toml` file configured for vendor sources. This means we can use vendor sources by default unless explicitly disabled with `build.vendor=false` by the user. So, let's do that.
