Fix `x test src/tools/error_index_generator --stage {0,1}`
There were two fixes needed:
1. Use `top_stage` instead of `top_stage - 1`. There was a long and torturous comment about trying to match rustdoc's version, but it works better without the hard-coding than with (before it gave errors that `libtest.so` couldn't be found).
2. Make sure that `ci-llvm/lib` is added to LD_LIBRARY_PATH. Previously the error index would be unable to load LLVM for stage0 builds.
At some point we should probably have a discussion about how rustdoc stages should be numbered;
confusion between 0/1/2 has come up several times in bootstrap now. cc https://github.com/rust-lang/rust/issues/92538
Note that this is still broken when using `download-rustc = true` and `--stage 1`,
but that's *really* a corner case and should affect almost no one. `--stage {0,2}`
work fine with download-rustc.
Fixes https://github.com/rust-lang/rust/issues/80096.
Report opaque type mismatches directly during borrowck of the function instead of within the `type_of` query.
This allows us to only store a single hidden type per opaque type instead of having to store one per set of substitutions.
r? `@compiler-errors`
This does not affect diagnostics, because the diagnostic messages are exactly the same.
Use gender neutral terms
#95508 was not executed well, but it did find a couple of legitimate issues: some uses of unnecessarily gendered language, and some typos. This PR fixes (properly) the legitimate issues it found.
Correct safety reasoning in `str::make_ascii_{lower,upper}case()`
I don't understand why the previous comment was used (it was inserted in #66564), but it doesn't explain why these functions are safe, only why `str::as_bytes{_mut}()` are safe.
If someone thinks they make perfect sense, I'm fine with closing this PR.
Regression test for #82866
Saw that this issue was open when i was cleaning my old branch for #92237.
I am also not opposed to not adding an extra test and just closing #82866.
Fixes#82866
Stop flagging unexpected inner attributes as outer ones in certain diagnostics
Fixes#94340.
In the issue to-be-fixed I write that the general message _an inner attribute is not permitted in this context_ should be more specific noting that the “context” is the `include` macro. This, however, cannot be achieved without touching a lot of things and passing a flag to the `parse_expr` and `parse_item` calls in `expand_include`. This seems rather hacky to me. That's why I left it as it. `Span::from_expansion` does not apply either AFAIK.
`@rustbot` label A-diagnostics T-compiler
Bump bootstrap compiler to 1.61.0 beta
This PR bumps the bootstrap compiler to the 1.61.0 beta. The first commit changes the stage0 compiler, the second commit applies the "mechanical" changes and the third and fourth commits apply changes explained in the relevant comments.
r? `@Mark-Simulacrum`
Rollup of 5 pull requests
Successful merges:
- #95352 ([bootstrap] Print the full relative path to failed tests)
- #95646 (Mention `std::env::var` in `env!`)
- #95708 (Update documentation for `trim*` and `is_whitespace` to include newlines)
- #95714 (Add test for issue #83474)
- #95725 (Message: Chunks cannot have a size of zero.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Mention `std::env::var` in `env!`
When searching for how to read an environment variable, I first encountered the `env!` macro. It would have been useful to me if the documentation had included a link to `std::env::var`, which is what I was actually looking for.
[bootstrap] Print the full relative path to failed tests
Before:
```
failures:
[ui] rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.rs
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 163 filtered out; finished in 0.45s
```
After:
```
failures:
[ui] src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.rs
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 163 filtered out; finished in 0.45s
```
This allows copy pasting the path or using Ctrl+Click in IDEs to go directly to the file, instead of having to edit the filename first.
By heap allocating the argument within `NtPath`, `NtVis`, and `NtStmt`.
This slightly reduces cumulative and peak allocation amounts, most
notably on `deep-vector`.
Update libc to 0.2.121
With the updated libc, UNIX stack overflow handling in libstd can now
use the common `si_addr` accessor function, rather than attempting to
use a field from that name in `siginfo_t`. This simplifies the
collection of the fault address, particularly on platforms where that
data resides within a union in `siginfo_t`.
Improve terse test output.
The current terse output gives 112 chars per line, which causes
wraparound for people using 100 char wide terminals, which is very
common.
This commit changes it to be exactly 100 wide, which makes the output
look much nicer.
Don't cast thread name to an integer for prctl
`libc::prctl` and the `prctl` definitions in glibc, musl, and the kernel headers are C variadic functions. Therefore, all the arguments (except for the first) are untyped. It is only the Linux man page which says that `prctl` takes 4 `unsigned long` arguments. I have no idea why it says this.
In any case, the upshot is that we don't need to cast the pointer to an integer and confuse Miri.
But in light of this... what are we doing with those three `0`s? We're passing 3 `i32`s to `prctl`, which doesn't fill me with confidence. The man page says `unsigned long` and all the constants in the linux kernel are macros for expressions of the form `1UL << N`. I'm mostly commenting on this because looks a whole lot like some UB that was found in SQLite a few years ago: <https://youtu.be/LbzbHWdLAI0?t=1925> that was related to accidentally passing a 32-bit value from a literal `0` instead of a pointer-sized value. This happens to work on x86 due to the size of pointers and happens to work on x86_64 due to the calling convention. But also, there is no good reason for an implementation to be looking at those arguments. Some other calls to `prctl` require that other arguments be zeroed, but not `PR_SET_NAME`... so why are we even passing them?
I would prefer to end such questions by either passing 3 `libc::c_ulong`, or not passing those at all, but I'm not sure which is better.
Rollup of 6 pull requests
Successful merges:
- #95342 (Ignore "format the world" commit in git blame)
- #95353 ([bootstrap] Give a hard error when filtering tests for a file that does not exist)
- #95649 (New mir-opt deref_separator)
- #95721 (Fix typo in bootstrap/setup.rs)
- #95730 (Rename RWLock to RwLock in std::sys.)
- #95731 (Check that all hidden types are the same and then deduplicate them.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Check that all hidden types are the same and then deduplicate them.
fixes#95538
This used to trigger a sanity check. Now we accept that there may be multiple places where a hidden type is constrained and we merge all of these at the end.
Ideally we'd merge eagerly, but that is a larger refactoring that I don't want to put into a backport
Rename RWLock to RwLock in std::sys.
std::sync::RwLock is spelled with two capital letters, but std::sys's RWLock was spelled with three capital letters. This cleans that up and uses `RwLock` everywhere.
New mir-opt deref_separator
This adds a new mir-opt that split certain derefs into this form:
`let x = (*a.b).c;` to => `tmp = a.b; let x = (*tmp).c;`
Huge thanks to ``@oli-obk`` for his patient mentoring.
[bootstrap] Give a hard error when filtering tests for a file that does not exist
A common issue people run into when running compiletest is that filtering for files that don't exist is only a warning and not an error; running the whole test suite instead.
See for example https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Question.20about.20compiletest.
This is especially bad when using `--bless`, which will modify all `.stderr` files.
Change bootstrap to require valid filters instead of discarding invalid filters and continuing.
Before:
```
Warning: Skipping "/home/jnelson/rust-lang/rust/src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.r": not a regular file or directory
Check compiletest suite=rustdoc-ui mode=ui (x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu) -> x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu))
running 163 tests
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii.......................... 100/163
...............................................................
test result: ok. 89 passed; 0 failed; 74 ignored; 0 measured; 0 filtered out; finished in 7.20s
finished in 7.248 seconds
Build completed successfully in 0:00:08
```
After:
```
thread 'main' panicked at 'Invalid test suite filter "/home/jnelson/rust-lang/rust/src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.r": file or directory does not exist', src/bootstrap/util.rs:311:
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:08
```
