| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
with namespace
|
|
|
|
r=GuillaumeGomez
make rustdoc::invalid_html_tags more robust
best reviewed a commit at a time.
I kept finding more edge case so I ended up having to make quite significant changes to the parser in order to make it preserve state across events and handle multiline attributes correctly.
fixes rust-lang/rust#145529
|
|
|
|
previously, this lint did not distinguish between `<img` and `<img>`,
and since the latter should be accepted under html5,
the former was also accepted.
the parser now also handles multi-line tags and multi-line attributes.
|
|
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
r=fmease,GuillaumeGomez
Don't emit `rustdoc::broken_intra_doc_links` for GitHub-flavored Markdown admonitions like `[!NOTE]`
fixes rust-lang/rust#141866
|
|
|
|
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (0xff9bf) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
|
|
lolbinarycat:rustdoc-intra-doc-link-warn-more-54191, r=GuillaumeGomez
get rid of some false negatives in rustdoc::broken_intra_doc_links
rustdoc will not try to do intra-doc linking if the "path" of a link looks too much like a "real url".
however, only inline links (`[text](url)`) can actually contain a url, other types of links (reference links, shortcut links) contain a *reference* which is later resolved to an actual url.
the "path" in this case cannot be a url, and therefore it should not be skipped due to looking like a url.
fixes https://github.com/rust-lang/rust/issues/54191
to minimize the number of false positives that will be introduced, the following heuristic is used:
If there's no backticks, be lenient revert to old behavior.
This is to prevent churn by linting on stuff that isn't meant to be a link.
only shortcut links have simple enough syntax that they
are likely to be written accidentlly, collapsed and reference links
need 4 metachars, and reference links will not usually use
backticks in the reference name.
therefore, only shortcut syntax gets the lenient behavior.
here's a truth table for how link kinds that cannot be urls are handled:
| | is shortcut link | not shortcut link |
|--------------|--------------------|-------------------|
| has backtick | never ignore | never ignore |
| no backtick | ignore if url-like | never ignore |
|
|
[rustdoc] Display total time and compilation time of merged doctests
Fixes rust-lang/rust#144270.
Does it look good to you `@kpreid?`
<img width="908" height="263" alt="image" src="https://github.com/user-attachments/assets/cd5d082d-c4e0-42ed-91dd-bd263b413dcd" />
|
|
|
|
|
|
collapsed links and reference links have a pretty particular syntax,
it seems unlikely they would show up on accident.
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
|
|
|
|
|
|
rustdoc will not try to do intra-doc linking if the "path"
of a link looks too much like a "real url".
however, only inline links ([text](url)) can actually contain
a url, other types of links (reference links, shortcut links)
contain a *reference* which is later resolved to an actual url.
the "path" in this case cannot be a url, and therefore it should
not be skipped due to looking like a url.
Co-authored-by: Michael Howell <michael@notriddle.com>
|
|
|
|
|
|
|
|
`TyCtxt::def_descr`
|
|
|
|
from expansion
|
|
Some rustdoc tests are `no_core` and need to have `MetaSized` and
`PointeeSized` added to them.
|
|
|
|
|
|
const-eval error: always say in which item the error occurred
I don't see why "is this generic" should make a difference. It may be reasonable to key this on whether the error occurs in a `const fn` that was invoked by a const (making it non-obvious which constant it is) vs inside the body of the const.
r? `@oli-obk`
|
|
Allow `#![doc(test(attr(..)))]` everywhere
This PR adds the ability to specify [`#![doc(test(attr(..)))]`](https://doc.rust-lang.org/nightly/rustdoc/write-documentation/the-doc-attribute.html#testattr) ~~at module level~~ everywhere in addition to allowing it at crate-root.
This is motivated by a recent PR #140323 (by ````@tgross35)```` where we have to duplicate 2 attributes to every single `f16` and `f128` doctests, by allowing `#![doc(test(attr(..)))]` at module level (and everywhere else) we can omit them entirely and just have (in both module):
```rust
#![doc(test(attr(feature(cfg_target_has_reliable_f16_f128))))]
#![doc(test(attr(expect(internal_features))))]
```
Those new attributes are appended to the one found at crate-root or at a previous module. Those "global" attributes are compatible with merged doctests (they already were before).
Given the small addition that this is, I'm proposing to insta-stabilize it, but I can feature-gate it if preferred.
Best reviewed commit by commit.
r? ````@GuillaumeGomez````
|
|
also adjust the wording a little so that we don't say "the error occurred here" for two different spans
|
|
Use the informative error as the main const eval error message
r? `@RalfJung`
I only did the minimal changes necessary to the const eval error machinery. I'd prefer not to mix test changes with refactorings 😆
|
|
|
|
|
|
|
|
r=GuillaumeGomez
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.
|
|
fixes https://github.com/rust-lang/rust/issues/91274
Co-authored-by: Guillaume Gomez <guillaume1.gomez@gmail.com>
|
|
|
|
r=GuillaumeGomez
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`
|
|
r=GuillaumeGomez
rustdoc: Replace unstable flag `--doctest-compilation-args` with a simpler one: `--doctest-build-arg`
Tracking issue: https://github.com/rust-lang/rust/issues/134172.
Context: https://github.com/rust-lang/rust/pull/137096#issuecomment-2776318800
Yeets the ad hoc shell-like lexer for 'nested' program arguments.
No FCP necessary since the flag is unstable.
I've chosen to replace `compilation` with `build` because it's shorter (you now need to pass it multiple times in order to pass many arguments to the doctest compiler, so it matters a bit) and since I prefer it esthetically.
**Issue**: Even though we don't process the argument passed to `--doctest-build-arg`, we end up passing it via an argument file (`rustc `@argfile`)` which delimits arguments by line break (LF or CRLF, [via](https://doc.rust-lang.org/rustc/command-line-arguments.html#path-load-command-line-flags-from-a-path)) meaning ultimately the arguments still get split which is unfortunate. Still, I think this change is an improvement over the status quo.
I'll update the tracking issue if/once this PR merges. I'll also add the (CR)LF issue to 'unresolved question'.
r? GuillaumeGomez
r? notriddle
|
|
Follow up https://github.com/rust-lang/rust/pull/127127
|
|
and migrate most of remaining `error-pattern`s to it.
|
