| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
Add keywords item into the sidebar
Fixes #62939.
cc @pravic
screenshot of the result:

r? @QuietMisdreavus
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Replace unsafe_destructor_blind_to_params with may_dangle
This PR will completely remove support for `#[unsafe_destructor_blind_to_params]` attribute,
which is deprecated in #38970 by `[may_dangle]` unsafe attribute.
Closes #34761
|
|
[rustdoc] Fix storage usage when disabled
Fixes #61239.
@starblue: Can you give a try to this change please? I tried on chrome and firefox and both worked so if you're using another web browser, that might be useful. :)
r? @Manishearth
|
|
Therefore we also remove `#[unsafe_destructor_blind_to_params]`
attribute completly.
|
|
It's internal to resolve and always results in `Res::Err` outside of resolve.
Instead put `DefKind::Fn`s themselves into the macro namespace, it's ok.
Proc macro stubs are items placed into macro namespase for functions that define proc macros.
https://github.com/rust-lang/rust/pull/52383
The rustdoc test is changed because the old test didn't actually reproduce the ICE it was supposed to reproduce.
|
|
|
|
Remove support for 1-token lookahead from the lexer
`StringReader` maintained `peek_token` and `peek_span_src_raw` for look ahead.
`peek_token` was used only by rustdoc syntax coloring. After moving peeking logic into highlighter, I was able to remove `peek_token` from the lexer. I tried to use `iter::Peekable`, but that wasn't as pretty as I hoped, due to buffered fatal errors. So I went with hand-rolled peeking.
After that I've noticed that the only peeking behavior left was for raw tokens to test tt jointness. I've rewritten it in terms of trivia tokens, and not just spans.
After that it became possible to simplify the awkward constructor of the lexer, which could return `Err` if the first peeked token contained error.
|
|
r=QuietMisdreavus
Fix code block information icon position
Fixes #62118.
A screenshot of the fix:
<img width="720" alt="Screenshot 2019-06-29 at 18 28 59" src="https://user-images.githubusercontent.com/3050060/60386900-edb23b80-9a9b-11e9-9f4f-0f343674348c.png">
r? @rust-lang/rustdoc
|
|
Remove needless lifetimes (std)
Split from #62039
|
|
|
|
The reader itself doesn't need ability to peek tokens, so it's better
if clients implement this functionality.
This hopefully becomes especially easy once we use iterator interface
for lexer, but this is not too easy at the moment, because of buffered
errors.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Move fs::create_dir_all calls into DocFS to provide a clean
extension point if async extension there is needed.
* Convert callsites of create_dir_all to ensure_dir to reduce syscalls.
* Convert fs::write usage to DocFS.write
(which also removes a lot of try_err! usage for easier reading)
* Convert File::create calls to use Vec buffers and then DocFS.write
in order to consistently reduce syscalls as well, make
deferring to threads cleaner and avoid leaving dangling content if
writing to existing files....
* Convert OpenOptions usage similarly - I could find no discussion on
the use of create_new for that one output file vs all the other
files render creates, if link redirection attacks are a concern
DocFS will provide a good central point to introduce systematic
create_new usage. (fs::write/File::create is vulnerable to link
redirection attacks).
* DocFS::write defers to rayon for IO on Windows producing a modest
speedup: before this patch on my development workstation:
$ time cargo +mystg1 doc -p winapi:0.3.7
Documenting winapi v0.3.7
Finished dev [unoptimized + debuginfo] target(s) in 6m 11s
real 6m11.734s
Afterwards:
$ time cargo +mystg1 doc -p winapi:0.3.7
Compiling winapi v0.3.7
Documenting winapi v0.3.7
Finished dev [unoptimized + debuginfo] target(s) in 49.53s
real 0m49.643s
I haven't measured how much time is in the compilation logic vs in the
IO and outputting etc, but this takes it from frustating to tolerable
for me, at least for now.
|
|
Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages
In the "Implementors" and "Implementations on Foreign Types" sections, only show methods that appear in the `impl` block for that type. This has the benefit of
- Reducing the size of the Iterator page, and other large trait documentation pages.
- Retaining documentation on the `impl` blocks and functions in the `impl` blocks.
- Indicating which provided methods are overridden.
- Making the documentation match the structure of the code being documented.
- Being a small change that can be easily backed out if issues arise.
A set of Rust stdlib docs build with this change are [available here](https://ebarnard.github.io/2019-06-03-rust-smaller-trait-implementers-docs/).
The size of the [`Iterator` doc page](https://ebarnard.github.io/2019-06-03-rust-smaller-trait-implementers-docs/std/iter/trait.Iterator.html) is reduced from 14.4MB (latest nightly) to 724kB.
Before:
<img width="1411" alt="Screenshot 2019-06-03 at 23 12 17" src="https://user-images.githubusercontent.com/1059683/58837971-1722a780-8655-11e9-8d81-51e48130951d.png">
After:
<img width="1428" alt="Screenshot 2019-06-03 at 16 41 27" src="https://user-images.githubusercontent.com/1059683/58814907-84ffac80-861e-11e9-8692-79be473a5299.png">
cc #55900
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implementors and Implementations on Foreign Types sections of trait documentation pages.
|
|
Fix duplicated bounds printing in rustdoc
Fixes #56331.
Once again, I couldn't find out how to reproduce it with a small code so no test... :-/
r? @QuietMisdreavus
|
|
r=Manishearth
Fix lines highlighting in rustdoc source view
Fixes #60948.
This PR fixes how we handle the lines highlighting from the URL (so in "/doc/src/alloc/string.rs.html#285-283", the "285-283" part). We got a hard limit on 50000, for some unknown and lost reasons which was used in case only one line is selected.
r? @Manishearth
|
|
Don't generate div inside header (h4/h3/h...) elements
Fixes #60865.
According to the HTML spec, we're not supposed to put `div` elements inside heading elements (h4/h3/h...). It doesn't change the display as far as I could tell.
r? @QuietMisdreavus
|
|
Fixes #60482.
|
|
|
|
We are going to uniform the terminology of all associated items.
Methods that may or may not have `self` are called "associated
functions". Because `AssociatedFn` is a bit long, we rename `Associated`
to `Assoc`.
|
|
|
|
|