rustdoc: linking to a local proc macro no longer warns
fixes https://github.com/rust-lang/rust/issues/91274
tried to keep the fix general in case we ever have any other kind of item that occupies
multiple namespaces simultaniously.
Make check-cfg diagnostics work in `#[doc(cfg(..))]`
This PR makes it so that the check-cfg `unexpected_cfgs` lint, is correctly emitted in `rustdoc`'s `#[doc(cfg(..))]`.
This is achieved by adding a custom trait to `cfg_matches` (the method that emits the lint) which permits `rustc` and `rustdoc` to each have their way to emitting lints (via buffered lints/AST for `rustc` and via `TyCtxt`/HIR for `rustdoc`).
The reason this is required is because buffered lints operates on the AST but `rustdoc` uses the HIR and by the time `rustdoc` calls `cfg_matches` we are way passed the point where buffered lints have been drain and emitted.
Best reviewed commit by commit.
r? `@jieyouxu` (for the compiler part)
r? `@GuillaumeGomez` (for the rustdoc part)
- `ret` only ever gets at most one entry, so it can be an `Option`
instead of a `Vec`.
- Which means we can use `filter_map` instead of `flat_map`.
- Move `trait_` next to the `ret` assignment, which can only happen
once.
- No need for `impls` to be a `Vec`, it can remain an iterator.
- Avoid `Result` when collecting `impls`.
It never fails, so it doesn't need to return `Result`. And the
`ItemType` in the result is just a copy of the one passed in via the
`shortty` arg, so it can also be removed.
Currently it is passed an `fqp` slice which it calls `to_vec` on and
returns. This is a bit odd. It's better to let the call site clone if
necessary. (One call site does, one does not).
Simplify `format_integer_with_underscore_sep`
Noticed that this helper fn only ever gets called with decimal-base-formatted ints, so can be simplified a lot by not trying to handle hex and octal radixes.
Second commit is completely unrelated, just simplified some code I wrote a while back 😁
Improve handling of rustdoc lints when used with raw doc fragments.
1. `rustdoc::bare_urls` no longer outputs incoherent suggestions if `source_span_for_markdown_range` returns None, instead outputting no suggestion
2. `source_span_for_markdown_range` has one more heuristic, so it will return `None` less often.
3. add ui test to make sure we don't emit nonsense suggestions.
fixes https://github.com/rust-lang/rust/issues/135851
1. rustdoc::bare_urls doesn't output
invalid suggestions if source_span_for_markdown_range
fails to find a span
2. source_span_for_markdown_range tries harder to
return a span by applying an additional diagnostic
fixes https://github.com/rust-lang/rust/issues/135851
Emit a warning if the doctest `main` function will not be run
Fixes#140310.
I think we could try to go much further like adding a "link" (ie UI annotations) on the `main` function in the doctest. However that will require some more computation, not sure if it's worth it or not. Can still be done in a follow-up if we want it.
For now, this PR does two things:
1. Pass the `DiagCtxt` to the doctest parser to emit the warning.
2. Correctly generate the `Span` to where the doctest is starting (I hope the way I did it isn't too bad either...).
cc `@fmease`
r? `@notriddle`