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.
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
```
interp/validity: enforce Scalar::Initialized
This is a follow-up to https://github.com/rust-lang/rust/pull/94527, to also account for the new kind of `Scalar` layout inside the validity checker.
r? `@oli-obk`
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.
enhance `ConstGoto` mir-opt by moving up `StorageDead` statements
From the `FIXME` in the implementation of `ConstGoto` miropt. We can move `StorageDead` statements up to the predecessor. This can expand the scope of application of this opt.
Update cargo
5 commits in 1ef1e0a12723ce9548d7da2b63119de9002bead8..e2e2dddebe66dfc1403a312653557e332445308b
2022-03-31 00:17:18 +0000 to 2022-04-05 17:04:53 +0000
- Part 2 of RFC2906 -- allow inheriting from a different `Cargo.toml` (rust-lang/cargo#10517)
- File Cache is valid if checkout or contents hasn't changed (rust-lang/cargo#10507)
- Fix how scrape-examples handles proc macros (rust-lang/cargo#10533)
- tools: update checkout action on CI (rust-lang/cargo#10521)
- Don't error if no binaries were installed (rust-lang/cargo#10508)
Rollup of 4 pull requests
Successful merges:
- #95659 (Rely on #[link] attribute for unwind on Fuchsia.)
- #95684 (rustdoc: Fix item info display overflow)
- #95693 (interp: pass TyCtxt to Machine methods that do not take InterpCx)
- #95699 (fix: Vec leak when capacity is 0)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
fix: Vec leak when capacity is 0
When `RawVec::with_capacity_in` is called with capacity 0, an allocation of size 0 is allocated.
However, `<RawVec as Drop>::drop` doesn't deallocate, since it only checks if capacity was 0. Fixed by not allocating when capacity is 0.
interp: pass TyCtxt to Machine methods that do not take InterpCx
This just seems like something you might need, so let's consistently have it.
One day we might have to add `ParamEnv` as well, though that seems less likely (and in Miri you can always use `reveal_all` anyway). It might make sense to have a type that packages `TyCtxt` and `ParamEnv`, this pairing occurs quite frequently in rustc...
r? `@oli-obk`
rustdoc: Fix item info display overflow
I came across this issue when reading local `Iterator` docs (reproduced in this screenshot):
The problem comes from the fact that `span` isn't `display: block` by default. Since `item-info` was already present on `<div>` in other places, I moved the last one to `div` as well.
r? `@notriddle`
Fix unsound `File` methods
This is a draft attempt to fix#81357. *EDIT*: this PR now tackles `read()`, `write()`, `read_at()`, `write_at()` and `read_buf`. Still needs more testing though.
cc `@jstarks,` can you confirm the the Windows team is ok with the Rust stdlib using `NtReadFile` and `NtWriteFile`?
~Also, I'm provisionally using `CancelIo` in a last ditch attempt to recover but I'm not sure that this is actually a good idea. Especially as getting into this state would be a programmer error so aborting the process is justified in any case.~ *EDIT*: removed, see comments.
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.
Currently it's called in `parse_tt` every time a match rule is invoked.
This commit moves it so it's called instead once per match rule, in
`compile_declarative_macro. This is a performance win.
The commit also moves `compute_locs` out of `TtParser`, because there's
no longer any reason for it to be in there.
Use revisions to track NLL test output (part 1)
The idea here is 2 fold: 1) When we eventually do make NLL default on, that PR should be systematic in "delete revisions and corresponding error annotations" 2) This allows us to look at test NLL outputs in chunks. (Though, I've opted here not to "mark" these tests. There are some tests with NLL revisions *now* that will be missed. I expect we do a second pass once we have all the tests with NLL revisions; these tests should be easy enough to eyeball.)
The actual review here should be "easy", but a bit tedious. I expect we should manually go through each test output and confirm it's okay.
The majority of these are either: 1) Only span change (the one I see most common is highlighting an entire function call, rather than just the function name in that call) 2) "E0308 mismatched types" -> "lifetime does not live long enough" 3) "E0495 cannot infer an appropriate lifetime for lifetime parameter" -> "lifetime does not live long enough" 4) "E0312 lifetime of reference outlives lifetime of borrowed content" -> "lifetime does not live long enough" 5) "E0759 `XXX` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement" -> "lifetime does not live long enough" 6) "E0623 lifetime mismatch" -> "lifetime does not live long enough"
Other than the now lack of an error code, most of these look fine (with most giving more helpful suggestions now).
`rfc1623` output isn't great.
cc ``@marmeladema`` if you want to look through these
Let's r? ``@oli-obk`` since you've commented on the Zulip thread ;)
