It's becoming more and more common to see people including markdown
files in their code using `doc = include_str!("...")`, which is great.
However, often there is no condition on this include, which is not great
because it slows down compilation and might trigger recompilation if
these files are updated.
This lint aims at fixing this situation.
changelog: Add new lint `doc_include_without_cfg`
The documentation for too_long_first_doc_paragraph incorrectly says
"line" where it should say "paragraph".
Fix a minor typo: doscstring -> docstring.
Also do a few tiny edits to attempt to make the wording slightly
shorter and clearer.
changelog: Edit documentation for [`too_long_first_doc_paragraph`]
Replacing an empty span (which an empty line is) with an empty string triggers a
debug assertion in rustc. This fixes the debug assertion by using contiguous
spans, with the same resulting suggestion.
chore: Ran cargo dev fmt
chore: Fixed spacing
fix: Fixed spacing for comment suggestion
fix: Added new module level test to too_long_first_doc_paragraph
chore: Ran cargo uibless
Fix case where doc_markdown is triggered on words ending with "ified"
Fixes#13097.
r? `@Alexendoo`
changelog: Fix case where doc_markdown is triggered on words ending with "ified"
* Construct lint passes by taking `Conf` by reference.
* Use `HashSet` configs in less places
* Move some `check_crate` code into the pass constructor when possible.
This change addresses cases where doc comments are separated
by blank lines, comments, or non-doc-comment attributes,
like this:
```rust
/// - first line
// not part of doc comment
/// second line
```
Before this commit, Clippy gave a pedantically-correct
warning about how you needed to indent the second line.
This is unlikely to be what the user intends, and has
been described as a "false positive" (since Clippy is
warning you about a highly unintuitive behavior that
Rustdoc actually has, we definitely want it to output
*something*, but the suggestion to indent was poor).
https://github.com/rust-lang/rust-clippy/issues/12917
The original message ("unsafe function's docs miss `# Safety` section")
reads quite awkwardly. I've changed it to "unsafe function's docs are missing
a `# Safety` section" to have it read better.
Signed-off-by: Paul R. Tagliamonte <paultag@gmail.com>
Currently we have an awkward mix of fallible and infallible functions:
```
new_parser_from_source_str
maybe_new_parser_from_source_str
new_parser_from_file
(maybe_new_parser_from_file) // missing
(new_parser_from_source_file) // missing
maybe_new_parser_from_source_file
source_str_to_stream
maybe_source_file_to_stream
```
We could add the two missing functions, but instead this commit removes
of all the infallible ones and renames the fallible ones leaving us with
these which are all fallible:
```
new_parser_from_source_str
new_parser_from_file
new_parser_from_source_file
source_str_to_stream
source_file_to_stream
```
This requires making `unwrap_or_emit_fatal` public so callers of
formerly infallible functions can still work.
This does make some of the call sites slightly more verbose, but I think
it's worth it for the simpler API. Also, there are two `catch_unwind`
calls and one `catch_fatal_errors` call in this diff that become
removable thanks this change. (I will do that in a follow-up PR.)
The `restriction` group contains many lints which are not about
necessarily “bad” things, but style choices — perhaps even style choices
which contradict conventional Rust style — or are otherwise very
situational. This results in silly wording like “Why is this bad?
It isn't, but ...”, which I’ve seen confuse a newcomer at least once.
To improve this situation, this commit replaces the “Why is this bad?”
section heading with “Why restrict this?”, for most, but not all,
restriction lints. I left alone the ones whose placement in the
restriction group is more incidental.
In order to make this make sense, I had to remove the “It isn't, but”
texts from the contents of the sections. Sometimes further changes
were needed, or there were obvious fixes to make, and I went ahead
and made those changes without attempting to split them into another
commit, even though many of them are not strictly necessary for the
“Why restrict this?” project.
This avoids event spans that would otherwise cause crashes, since an
End's span covers the range of the tag (which will be earlier than the
line break within the tag).
This is a follow-up for https://github.com/rust-lang/rust/pull/121659,
since most cases of unintended block quotes are lazy continuations.
The lint is designed to be more generally useful than that, though,
because it will also catch unintended list items and unintended
block quotes that didn't coincidentally hit a pulldown-cmark bug.
Currently `SourceMap` is constructed slightly later than
`SessionGlobals`, and inserted. This commit changes things so they are
done at the same time.
Benefits:
- `SessionGlobals::source_map` changes from
`Lock<Option<Lrc<SourceMap>>>` to `Option<Lrc<SourceMap>>`. It's still
optional, but mutability isn't required because it's initialized at
construction.
- `set_source_map` is removed, simplifying `run_compiler`, which is
good because that's a critical function and it's nice to make it
simpler.
This requires moving things around a bit, so the necessary inputs are
available when `SessionGlobals` is created, in particular the `loader`
and `hash_kind`, which are no longer computed by `build_session`. These
inputs are captured by the new `SourceMapInputs` type, which is threaded
through various places.
