Make AIX known by bootstrap
Use `x.py` to build rustc on AIX directly is failing
```
unknown OS type: AIX
Build completed unsuccessfully in 0:00:00
```
If kernel is `AIX`, we should return default triple `powerpc64-ibm-aix` for current rustc.
modify fuction clond() -> cloned()
optimize the code
Handle the problem that the pathset is empty and modify the judgment of the builder::tests::test_exclude_kind
Delete unnecessary judegment conditions
skip test for library/std duo to OOM in benches as library/alloc
Add FIXME for WASM32
coverage: Explicitly test the coverage maps produced by codegen/LLVM
Our existing coverage tests verify the output of end-to-end coverage reports, but we don't have any way to test the specific mapping information (code regions and their associated counters) that are emitted by `rustc_codegen_llvm` and LLVM. That makes it harder to to be confident in changes that would modify those mappings (whether deliberately or accidentally).
This PR addresses that by adding a new `coverage-map` test suite that does the following:
- Compiles test files to LLVM IR assembly (`.ll`)
- Feeds those IR files to a custom tool (`src/tools/coverage-dump`) that extracts and decodes coverage mappings, and prints them in a more human-readable format
- Checks the output of that tool against known-good snapshots
---
I recommend excluding the last commit while reviewing the main changes, because that last commit is just ~40 test files copied over from `tests/run-coverage`, plus their blessed coverage-map snapshots and a readme file. Those snapshots aren't really intended to be checked by hand; they're mostly there to increase the chances that an unintended change to coverage maps will be observable (even if it requires relatively specific circumstances to manifest).
support `{disable,enable}-patch-binaries-for-nix` in configure.py
Provide the control of `patch-binaries-for-nix` flag from configure.py without requiring manual editing.
It's useful when:
bf1e3f31f9/src/bootstrap/bootstrap.py (L661-L667)
We compile each test file to LLVM IR assembly, and then pass that IR to a
dedicated program that can decode LLVM coverage maps and print them in a more
human-readable format. We can then check that output against known-good
snapshots.
This test suite has some advantages over the existing `run-coverage` tests:
- We can test coverage instrumentation without needing to run target binaries.
- We can observe subtle improvements/regressions in the underlying coverage
mappings that don't make a visible difference to coverage reports.
avoid stdout redirection on `curl` executions
Avoid redirecting the curl output directly to the stdout. This alteration affects the integrity of the file during the retry process, as it also redirects the logs from the retries. Consequently, this leads to the bootstrap process failing because of an invalid checksum.
For more information, see the [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/checksum.20errors)
Fixes#115275
Avoid redirecting the curl output directly to the stdout. This alteration
affects the integrity of the file during the retry process, as it also redirects
the logs from the retries. Consequently, this leads to the bootstrap process failing
because of an invalid checksum.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
compile rust-anaylzer with `x check` if it's enabled
By default, `x check` doesn't compile the rust-analyzer. But when it's enabled in the config's tools section, there's no reason not to do it. This change allows `x check` to compile rust-analyzer if it's enabled in config's tools section.
Helps to #115031
Detect and report nix shell
Better diagnostics for people using nix subshell on non-NixOS.
1. Turned patch-binaries-for-nix from a boolean into a ternary flag: true, false, and unset.
2. When patch-binaries-for-nix is unset, we continue with the existing NixOS detection heuristic (look for nixos in /etc/os-release, if present), but if we are not atop NixOS, then issue a note if we see the IN_NIX_SHELL environment variable telling the user to consider setting patch-binaries-for-nix explicitly.
Fix#115073
In addition: Incorporated some review feedback (namely, removed a useless
initial assignment to True that was never read), and unified code a bit more
between bootstrap.py and download.rs (by using the same variable name for the
same concept).
Skip ExpandYamlAnchors when the config is missing
The dist-src tarball does not include `.github/` at all, so we can't
check whether it needs to be regenerated.
1. Turned patch-binaries-for-nix from a boolean into a ternary flag: true,
false, and unset.
2. When patch-binaries-for-nix is unset, we continue with the existing NixOS
detection heuristic (look for nixos in /etc/os-release, if present), but if
we are not atop NixOS, then issue a note if we see the IN_NIX_SHELL
environment variable telling the user to consider setting
patch-binaries-for-nix explicitly.
By default, `x check` doesn't compile the rust-analyzer. But when it's enabled in the config's
tools section, there's no reason not to do it. This change allows `x check` to compile rust-analyzer
if it's enabled in config's tools section.
Signed-off-by: ozkanonur <work@onurozkan.dev>
Always use `os-release` rather than `/lib` to detect `NixOS` (bootstrap)
[Two users over on zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Bootstrapping.20on.20NixOS) bumped into issues where NixOS wasn't being properly detected.
I believe this was caused by the presence of `/lib` on their machines. `/lib` is not standard on NixOS but can still be created by users or scripts.
We are already checking `/etc/os-release`. The presence of `ID=nixos` in it's output should be trustworthy and we shouldn't then go on to also check for `/lib`.
Warn on elided lifetimes in associated constants (`ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT`)
Elided lifetimes in associated constants (in impls) erroneously resolve to fresh lifetime parameters on the impl since #97313. This is not correct behavior (see #38831).
I originally opened #114716 to fix this, but given the time that has passed, the crater results seem pretty bad: https://github.com/rust-lang/rust/pull/114716#issuecomment-1682091952
This PR alternatively implements a lint against this behavior, and I'm hoping to bump this to deny in a few versions.
[Two users over on zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Bootstrapping.20on.20NixOS) bumped into issues where NixOS wasn't being properly detected.
I believe this was caused by the presence of `/lib` on their machines. `/lib` is not standard on NixOS but can still be created by users or scripts.
We are already checking `/etc/os-release`. The presence of `ID=nixos` in it's output should be trustworthy and we shouldn't then go on to also check for `/lib`.
