This commit refactors the implementation of
`markdown_summary_with_limit()`, separating the logic of determining
when the limit has been reached from the actual rendering process.
The main advantage of the new approach is that it guarantees that all
HTML tags are closed, whereas the previous implementation could generate
tags that were never closed. It also ensures that no empty tags are
generated (e.g., `<em></em>`).
The new implementation consists of a general-purpose struct
`HtmlWithLimit` that manages the length-limiting logic and a function
`markdown_summary_with_limit()` that renders Markdown to HTML using the
struct.
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
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`
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`
```
Include (potentially remapped) working dir in crate hash
Fixes#85019
A `SourceFile` created during compilation may have a relative
path (e.g. if rustc itself is invoked with a relative path).
When we write out crate metadata, we convert all relative paths
to absolute paths using the current working directory.
However, the working directory is not included in the crate hash.
This means that the crate metadata can change while the crate
hash remains the same. Among other problems, this can cause a
fingerprint mismatch ICE, since incremental compilation uses
the crate metadata hash to determine if a foreign query is green.
This commit moves the field holding the working directory from
`Session` to `Options`, including it as part of the crate hash.
cc `@ohsayan`
Skip assert ICE with default_method_body_is_const
functions marked with #[default_method_body_is_const] would
ICE when being const checked due to it not being a const function:
`tcx.is_const_fn_raw(did)` returns false. We should skip this assert
when it is marked with that attribute.
r? `@oli-obk`
Enable `--all-targets` for `x.py check` unconditionally
Now that Cargo deduplicates diagnostics from different targets, this doesn't flood the console with
duplicate errors.
Note that this doesn't add `--all-targets` in `Builder::cargo` directly because `impl Step for Std`
actually wants to omit `--all-targets` the first time while it's still building libtest.
When passed `--all-targets`, this warns that the option isn't needed, but still continues to compile.
Fixes https://github.com/rust-lang/rust/issues/87846.
r? ``@Mark-Simulacrum``
Closure migration multispan suggestions
This changes the `rust_2021_incompatible_closure_captures` lint to only suggest inserting the parts that need to be inserted, instead of suggesting to replace the entire closure by an almost identical closure with one statement added.
Before:
```
[...]
help: add a dummy let to cause `a` to be fully captured
|
5 ~ let _ = || {
6 + let _ = &a;
7 + dbg!(a.0);
8 + println!("1");
9 + println!("2");
10 + println!("3");
...
|
[...]
help: add a dummy let to cause `b` to be fully captured
|
14 | let _ = || { let _ = &b; dbg!(b.0); };
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
help: add a dummy let to cause `c` to be fully captured
|
16 | let _ = || { let _ = &c; dbg!(c.0) };
| ~~~~~~~~~~~~~~~~~~~~~~~~~
```
After:
```
[...]
help: add a dummy let to cause `a` to be fully captured
|
5 ~ let _ = || {
6 + let _ = &a;
|
[...]
help: add a dummy let to cause `b` to be fully captured
|
14 | let _ = || { let _ = &b; dbg!(b.0); };
| +++++++++++
[...]
help: add a dummy let to cause `c` to be fully captured
|
16 | let _ = || { let _ = &c; dbg!(c.0) };
| +++++++++++++ +
```
[rustdoc] Copy only item path to clipboard rather than full `use` statement.
The (somewhat) recent addition of the "copy item import to clipboard" button is extremely nice.
However, i tend to write my code with fully qualified paths wherever feasible and only resort to `use` statements as a refactoring pass. This makes the "copy to clipboard" workflow awkward to use, as i would be copy-pasting that as, say
```rust
impl use std::ops::Add; for MyType {
```
and then go back and remove the `use ` and `;`.
This PR removes the `use ;` decorations, making it much nicer to use for fully-qualified items. I argue, however, that this does not noticeably degrade experience for those who prefer to import items, since the hard part about those is getting the path right, and writing the `use ;` decoration can be done by hand with little effort.
Add future-incompat lint for `doc(primitive)`
## What is `doc(primitive)`?
`doc(primitive)` is an attribute recognized by rustdoc which adds documentation for the built-in primitive types, such as `usize` and `()`. It has been stable since Rust 1.0.
## Why change anything?
`doc(primitive)` is useless for anyone outside the standard library. Since rustdoc provides no way to combine the documentation on two different primitive items, you can only replace the docs, and since the standard library already provides extensive documentation there is no reason to do so.
While fixing rustdoc's handling of primitive items (https://github.com/rust-lang/rust/pull/87073) I discovered that even rustdoc's existing handling of primitive items was broken if you had more than two crates using it (it would pick randomly between them). That meant both:
- Keeping rustdoc's existing treatment was nigh-impossible, because it was random.
- doc(primitive) was even more useless than it would otherwise be.
The only use-case for this outside the standard library is for no-std libraries which want to link to primitives (https://github.com/rust-lang/rust/issues/73423) which is being fixed in https://github.com/rust-lang/rust/pull/87073.
https://github.com/rust-lang/rust/pull/87073 makes various breaking changes to `doc(primitive)` (breaking in the sense that they change the semantics, not in that they cause code to fail to compile). It's not possible to avoid these and still fix rustdoc's issues.
## What can we do about it?
As shown by the crater run (https://github.com/rust-lang/rust/pull/87050#issuecomment-886166706), no one is actually using doc(primitive), there wasn't a single true regression in the whole run. We can either:
1. Feature gate it completely, breaking anyone who crater missed. They can easily fix the breakage just by removing the attribute.
2. add it to the `INVALID_DOC_ATTRIBUTES` future-incompat lint, and at the same time make it a no-op unless you add a feature gate. That would mean rustdoc has to look at the features of dependent crates, because it needs to know where primitives are defined in order to link to them.
3. add it to `INVALID_DOC_ATTRIBUTES`, but still use it to determine where primitives come from
4. do nothing; the behavior will silently change in https://github.com/rust-lang/rust/pull/87073.
My preference is for 2, but I would also be happy with 1 or 3. I don't think we should silently change the behavior.
This PR currently implements 3.
