Prevent double panic when handling incremental fingerprint mismatch
When an incremental fingerprint mismatch occurs, we debug-print
our `DepNode` and query result. Unfortunately, the debug printing
process may cause us to run additional queries, which can result
in a re-entrant fingerprint mismatch error.
To avoid a double panic, this commit adds a thread-local variable
to detect re-entrant calls.
Rollup of 10 pull requests
Successful merges:
- #87818 (Fix anchors display in rustdoc)
- #87983 (Use more accurate spans when proposing adding lifetime to item)
- #88012 (Change WASI's `RawFd` from `u32` to `c_int` (`i32`).)
- #88031 (Make `BuildHasher` object safe)
- #88036 (Fix dead code warning when inline const is used in pattern)
- #88082 (Take into account jobs number for rustdoc GUI tests)
- #88109 (Fix environment variable getter docs)
- #88111 (Add background-color on clickable definitions in source code)
- #88129 (Fix dataflow graphviz bug, make dataflow graphviz modules public)
- #88136 (Move private_unused.rs test to impl-trait)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Move private_unused.rs test to impl-trait
This test was added to fix this issue #55124 which is about impl traits but not related with type alias impl traits.
r? `@oli-obk`
`@bors` rollup=always
Fix dataflow graphviz bug, make dataflow graphviz modules public
I'm working on a rustc plugin that uses the dataflow framework for MIR analysis. I've found the graphviz utilities extremely helpful for debugging. However, I had to fork the compiler to expose them since they're currently private. I would appreciate if they could be made public so I can build against a nightly instead of a custom fork. Specifically, this PR:
* Makes public the `rustc_mir::dataflow::framework::graphviz` module.
* Makes public the `rustc_mir::util::pretty::write_mir_fn` function.
Here's a concrete example of how I'm using the graphviz module: 97b843b8b0/src/slicing/mod.rs (L186-L203)
Additionally, this PR fixes a small bug in the diff code that incorrectly shows the updated object as the old object.
r? `@ecstatic-morse`
Fix environment variable getter docs
`@RalfJung` pointed out a number of errors and suboptimal choices I made in my documentation for #86183. This PR should (hopefully) fix the problems they've identified.
Change WASI's `RawFd` from `u32` to `c_int` (`i32`).
WASI previously used `u32` as its `RawFd` type, since its "file descriptors"
are unsigned table indices, and there's no fundamental reason why WASI can't
have more than 2^31 handles.
However, this creates myriad little incompability problems with code
that also supports Unix platforms, where `RawFd` is `c_int`. While WASI
isn't a Unix, it often shares code with Unix, and this difference made
such shared code inconvenient. #87329 is the most recent example of such
code.
So, switch WASI to use `c_int`, which is `i32`. This will mean that code
intending to support WASI should ideally avoid assuming that negative file
descriptors are invalid, even though POSIX itself says that file descriptors
are never negative.
This is a breaking change, but `RawFd` is considerd an experimental
feature in [the documentation].
[the documentation]: https://doc.rust-lang.org/stable/std/os/wasi/io/type.RawFd.html
r? `@alexcrichton`
Matthew's work on improving NLL's "higher-ranked subtype error"s
This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374.
These are a blocker to turning full NLLs on, and doing some internal cleanups to remove some of the old region code.
The goal is so `@nikomatsakis` can take a look at this early, and I'll then do my best to help do the changes and followup work to land this work, and move closer to turning off the migration mode.
I've only updated the branch and made it compile, removed a warning or two.
r? `@nikomatsakis`
(Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)
Update cargo
8 commits in b51439fd8b505d4800a257acfecf3c69f81e35cf..e96bdb0c3d0a418e7fcd7fbd69be08abf830b4bc
2021-08-09 18:40:05 +0000 to 2021-08-17 22:58:47 +0000
- Support using rustbot to ping the Windows group (rust-lang/cargo#9802)
- Show information about abnormal `fix` errors. (rust-lang/cargo#9799)
- Bump jobserver. (rust-lang/cargo#9798)
- Render build-std web links as hyperlinks (rust-lang/cargo#9795)
- Teach cargo to failfast on recursive/corecursive aliases (rust-lang/cargo#9791)
- Fix value-after-table error with profiles. (rust-lang/cargo#9789)
- Fix plugin registrar change. (rust-lang/cargo#9790)
- Ability to specify the output name for a bin target different from the crate name (rust-lang/cargo#9627)
Remove box syntax from compiler and tools
Removes box syntax from the compiler and tools. In #49733, the future of box syntax is uncertain and the use in the compiler was listed as one of the reasons to keep it. Removal of box syntax [might affect the code generated](https://github.com/rust-lang/rust/pull/49646#issuecomment-379219615) and slow down the compiler so I'd recommend doing a perf run on this.
Update `polonius-engine` to 0.13.0
This PR updates the use of `polonius-engine` to the recently released 0.13.0:
- this version renamed a lot of relations to match the current terminology
- "illegal subset relationships errors" (AKA "subset errors" or "universal region errors" in rustc parlance) have been implemented in all variants, and therefore the `Hybrid` variant can be the rustc default once again
- some of the blessed expectations were updated: new tests have been added since the last time I updated the tests, diagnostics have changed, etc.
In particular:
- a few tests had trivial expectations changes such as basic diagnostics changes for the migrate-mode and full NLLs
- others were recursion and lengths limits which emits a file, and under the polonius compare-mode, the folder has a different name
- a few tests were ignored in the NLL compare-mode for reasons that obviously also apply to Polonius
- some diagnostics were unified so that older expectations no longer made sense: the NLL and Polonius outputs were identical.
- in a few cases Polonius gets a chance to emit more errors than NLLs
A few tests in the compare-mode still are super slow and trigger the 60s warning, or OOM rustc during fact generation, and I've detailed these [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/186049-t-compiler.2Fwg-polonius/topic/Challenges.20for.20move.2Finit.2C.20liveness.2C.20and.20.60Location.3A.3AAll.60):
- `src/test/ui/numbers-arithmetic/saturating-float-casts.rs` -> OOM during rustc fact generation
- `src/test/ui/numbers-arithmetic/num-wrapping.rs`
- `src/test/ui/issues/issue-72933-match-stack-overflow.rs`
- `src/test/ui/issues/issue-74564-if-expr-stack-overflow.rs`
- `src/test/ui/repr/repr-no-niche.rs`
In addition, 2 tests don't currently pass and I didn't want to bless them now: they deal with HRTBs and miss errors that NLLs emit. We're currently trying to see if we need chalk to deal with HRTB errors (as we thought we would have to) but during the recent sprint, we discovered that we may be able to detect some of these errors in a way that resembles subset errors:
- `ui/hrtb/hrtb-just-for-static.rs` -> 3 errors in NLL, 2 in polonius: a missing error about HRTB + needing to outlive 'static
- `ui/issues/issue-26217.rs` -> missing HRTB that makes the test compile instead of emitting an error
We'll keep talking about this at the next sprint as well.
cc `@rust-lang/wg-polonius` r? `@nikomatsakis`
Enable compiler consumers to obtain mir::Body with Polonius facts.
This PR adds a function (``get_body_with_borrowck_facts``) that can be used by compiler consumers to obtain ``mir::Body`` with accompanying borrow checker information.
The most important borrow checker information that [our verifier called Prusti](https://github.com/viperproject/prusti-dev) needs is lifetime constraints. I have not found a reasonable way to compute the lifetime constraints on the Prusti side. In the compiler, the constraints are computed during the borrow checking phase and then dropped. This PR adds an additional parameter to the `do_mir_borrowck` function that tells it to return the computed information instead of dropping it.
The additionally returned information by `do_mir_borrowck` contains a ``mir::Body`` with non-erased lifetime regions and Polonius facts. I have decided to reuse the Polonius facts because this way I needed fewer changes to the compiler and Polonius facts contains other useful information that we otherwise would need to recompute.
Just FYI: up to now, Prusti was obtaining this information by [parsing the compiler logs](b58ced8dfd/prusti-interface/src/environment/borrowck/regions.rs (L25-L39)). This is not only a hacky approach, but we also reached its limits.
r? `@nikomatsakis`
Improve non_fmt_panics suggestion based on trait impls.
This improves the non_fmt_panics lint suggestions by checking first which trait (Display or Debug) are actually implemented on the type.
Fixes https://github.com/rust-lang/rust/issues/87313
Fixes https://github.com/rust-lang/rust/issues/87999
Before:
```
help: add a "{}" format string to Display the message
|
2 | panic!("{}", Some(1));
| +++++
help: or use std::panic::panic_any instead
|
2 | std::panic::panic_any(Some(1));
| ~~~~~~~~~~~~~~~~~~~~~
```
After:
```
help: add a "{:?}" format string to use the Debug implementation of `Option<i32>`
|
2 | panic!("{:?}", Some(1));
| +++++++
help: or use std::panic::panic_any instead
|
2 | std::panic::panic_any(Some(1));
| ~~~~~~~~~~~~~~~~~~~~~
```
r? `@estebank`
Revert "Auto merge of #83417 - erikdesjardins:enableremovezsts, r=oli-obk"
This reverts commit 8007b506ac, reversing changes made to e55c13e109.
Fixes#88043
r? `@oli-obk`
The libs-api team agrees to allow const_trait_impl to appear in the
standard library as long as stable code cannot be broken (they are
properly gated) this means if the compiler teams thinks it's okay, then
it's okay.
My priority on constifying would be:
1. Non-generic impls (e.g. Default) or generic impls with no
bounds
2. Generic functions with bounds (that use const impls)
3. Generic impls with bounds
4. Impls for traits with associated types
For people opening constification PRs: please cc me and/or oli-obk.
Use note for pointing at bound introducing requirement
Modify output for pointing where a trait bound obligation is introduced in an E0277 from using a span label to using a note in order to always preserve order of the output:
Before:
```
error[E0277]: `<<Self as Case1>::A as Iterator>::Item` doesn't implement `Debug`
--> $DIR/bounds-on-assoc-in-trait.rs:18:28
|
LL | type A: Iterator<Item: Debug>;
| ^^^^^ `<<Self as Case1>::A as Iterator>::Item` cannot be formatted using `{:?}` because it doesn't implement `Debug`
|
::: $SRC_DIR/core/src/fmt/mod.rs:LL:COL
|
LL | pub trait Debug {
| --------------- required by this bound in `Debug`
|
= help: the trait `Debug` is not implemented for `<<Self as Case1>::A as Iterator>::Item`
```
After:
```
error[E0277]: `<<Self as Case1>::A as Iterator>::Item` doesn't implement `Debug`
--> $DIR/bounds-on-assoc-in-trait.rs:18:28
|
LL | type A: Iterator<Item: Debug>;
| ^^^^^ `<<Self as Case1>::A as Iterator>::Item` cannot be formatted using `{:?}` because it doesn't implement `Debug`
|
= help: the trait `Debug` is not implemented for `<<Self as Case1>::A as Iterator>::Item`
note: required by a bound in `Debug`
--> $SRC_DIR/core/src/fmt/mod.rs:LL:COL
|
LL | pub trait Debug {
| ^^^^^^^^^^^^^^^ required by this bound in `Debug`
```
