| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Respect `-Z` unstable options in `rustdoc --test`
This PR makes rustdoc respect `-Z` unstable options when collecting doctests (`rustdoc --test`).
In the process I also realized that `--error-format` wasn't respected as well, making UI annotations impossible to write so I fixed that as well.
Best reviewed commit by commit.
Fixes https://github.com/rust-lang/rust/issues/147276
Fixes https://github.com/rust-lang/rust/issues/143930
r? fmease
|
|
|
|
|
|
|
|
|
|
GuillaumeGomez:fix-doctest-compilation-time-display, r=lolbinarycat
Fix doctest compilation time display
Fixes rust-lang/rust#146960.
Small corner case that happened in case everything went fine and there was only merged doctests.
r? lolbinarycat
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 😆
|
|
|
|
|
