librustc_lint: In recursion warning, change 'recurring' to 'recursing'
The existing wording seems incorrect.
Aside: This warning, 'function cannot return without recursing' is not perfectly clear - it implies that the function _can_ return, it's just got to recurse. But really the fn cannot return period. Clearer wording: 'function recurses infinitely; it cannot return'; or 'function is infinitely self-recursive; it cannot return, and this is probably an error'. I like that.
Andrew Chin recently pointed out (rust-lang/cargo#5846) that it's
surprising that `cargo fix` (now shipping with Cargo itself!) doesn't
fix very common lint warnings, which is as good of a reminder as any
that we should finish #50723.
This commit polishes off this new function to compile on newer rustc as well as
update and add a suite of test cases to work with this new check for lints.
If the item is `pub`, one imagines users being confused as to why it's
not reachable/exported; a code suggestion is beyond our local knowledge
here, but we can at least offer a prose hint. (Thanks to Vadim
Petrochenkov for shooting down the present author's original bad idea
for the note text.)
While we're here, use proper HELP expectations instead of ad hoc
comments to communicate (and now, enforce) the expected suggestions in
test/ui/lint/suggestions.rs.
This is probably quite a lot less likely to come up in practice than the
"inherited" (no visibility keyword) case, but now that we have
visibility spans in the HIR, we can do this, and it presumably doesn't
hurt to be exhaustive. (Who can say but that the attention to detail
just might knock someone's socks off, someday, somewhere?)
This is inspired by #47383.
Our implementation ends up changing the `PatKind::Range` variant in the
AST to take a `Spanned<RangeEnd>` instead of just a `RangeEnd`, because
the alternative would be to try to infer the span of the range operator
from the spans of the start and end subexpressions, which is both
hideous and nontrivial to get right (whereas getting the change to the
AST right was a simple game of type tennis).
This is concerning #51043.
The top level message shouldn't be too long; the
replaced-by-coercion/temporary-variable advice can live in a note. Also,
don't mention type ascription when it's not actually available as a real
thing. (The current state of discussion on the type ascription tracking
issue #23416 makes one rather suspect it will never be a stable thing in
its current form, but that's not for us to adjudicate in this commit.)
While we're here, yank out the differentiating parts of the
numeric/other conditional and only have one codepath emitting the
diagnostic.
Rollup of 8 pull requests
Successful merges:
- #50531 (Cleanup uses of TypeIdHasher and replace them with StableHasher)
- #50819 (Fix potential divide by zero)
- #50827 (Update LLVM to 56c931901cfb85cd6f7ed44c7d7520a8de1edf97)
- #50829 (CheckLoopVisitor: also visit break expressions)
- #50854 (in which the unused shorthand field pattern debacle/saga continues)
- #50858 (Reorder description for snippets in rustdoc documentation)
- #50883 (Fix warning when building stage0 libcore)
- #50889 (Update clippy)
Failed merges:
In e4b1a79 (#47922), we corrected erroneous suggestions for unused
shorthand field pattern bindings, suggesting `field: _` where the
previous suggestion of `_field` wouldn't even have compiled
(#47390). Soon, it was revealed that this was insufficient (#50303), and
the fix was extended to references, slices, &c. (#50327) But even this
proved inadequate, as the erroneous suggestions were still being issued
for patterns in local (`let`) bindings (#50804). Here, we yank the
shorthand-detection and variable/node registration code into a new
common function that can be called while visiting both match arms and
`let` bindings.
Resolves#50804.
The Higher Intermediate Representation doesn't have spans for visibility
keywords, so we were assuming that the first whitespace-delimited token
in the item span was the `pub` to be weakened. This doesn't work for
brace-grouped `use`s, which get lowered as if they were several
individual `use` statements, but with spans that only cover the braced
path-segments. Constructing a correct suggestion here presents some
challenges—until someone works those out, we can at least protect the
dignity of our compiler marking the suggestion for `use` items as
potentially incorrect.
This resolves#50455 (but again, it would be desirable in the future to
make a correct suggestion instead of copping out like this).
