| Age | Commit message (Collapse) | Author | Lines |
|
in source rendering
|
|
|
|
resolve: Collapse `macro_rules` scope chains on the fly
Otherwise they grow too long and you have to endlessly walk through them when resolving macros or imports.
Addresses https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Slow.20Builtin.20Derives/near/215750815
|
|
Rollup of 5 pull requests
Successful merges:
- #78916 (extend const generics test suite)
- #78921 (Improve the page title switch handling between search and doc)
- #78933 (Don't print thread ids and names in `tracing` logs)
- #78960 (Test default values for const parameters.)
- #78971 (Update books)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Improve the page title switch handling between search and doc
The current behavior often "forgets" to update the page title when discarding/putting back the search results. This isn't optimal which is why I wrote this fix.
r? ``@jyn514``
|
|
Add shortcut for theme picker menu
Follow-up of #78584
Just like you can focus the search input by pressing "S", you can now access the theme picker menu by pressing "T" and navigate through the options only using the keyboard.
cc `@notriddle`
r? `@jyn514`
|
|
Cleanup and comment intra-doc link pass
r? ```@Manishearth```
cc ```@seeplusplus```
|
|
The discussion seems to have resolved that this lint is a bit "noisy" in
that applying it in all places would result in a reduction in
readability.
A few of the trivial functions (like `Path::new`) are fine to leave
outside of closures.
The general rule seems to be that anything that is obviously an
allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it
is a 0-sized allocation.
|
|
|
|
|
|
Previously the [src] link on types defined by a macro
pointed to the macro definition.
This commit makes the Clean-Implementation for Spans
aware of macro defined types,
so that the link points to the invocation instead.
|
|
Fix tab focus on restyled switches
Setting a checkbox to `display:none` makes it impossible to tab onto it, which makes the rustdoc settings page completely keyboard inaccessible.
|
|
Recognize `private_intra_doc_links` as a lint
Previously, trying to allow this would give another error!
```
warning: unknown lint: `private_intra_doc_links`
--> private.rs:1:10
|
1 | #![allow(private_intra_doc_links)]
| ^^^^^^^^^^^^^^^^^^^^^^^ help: did you mean: `broken_intra_doc_links`
|
= note: `#[warn(unknown_lints)]` on by default
warning: public documentation for `DocMe` links to private item `DontDocMe`
--> private.rs:2:11
|
2 | /// docs [DontDocMe]
| ^^^^^^^^^ this item is private
|
= note: `#[warn(private_intra_doc_links)]` on by default
= note: this link will resolve properly if you pass `--document-private-items`
```
Fixes the issue found in https://github.com/rust-lang/rust/pull/77249#issuecomment-712339227.
r? ````````@Manishearth````````
Does anyone know why this additional step is necessary? It seems weird this has to be declared in 3 different places.
|
|
Setting a checkbox to `display:none` makes it impossible to tab onto it,
which makes the rustdoc settings page completely keyboard inaccessible.
|
|
|
|
75521 rustdoc book improvements
Added some guidelines about documenting with rustdoc
Fixes #75521
|
|
Add non_autolinks lint
Part of #77501.
r? `@jyn514`
|
|
|
|
This is really starting to get out of hand. Rustdoc should instead allow
all lints in the rustdoc lint group.
|
|
|
|
Add keyboard handling to the theme picker menu
This PR is mostly designed to bring the theme picker closer to feature parity with the menu bar from docs.rs. Though the rustdoc theme picker is technically already usable from the keyboard, it's really weird that arrow keys work on some of the menus, but not all of them, in the exact same page.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
|
|
|
|
|
|
Fix unindent in doc comments
Fixes #70732
r? ``@jyn514``
|
|
|
|
Most of the code in mod.rs should be code that really needs to have
the list of available themes inlined into it.
|
|
|
|
|
|
This is mostly motivated by docs.rs. It's really weird
when arrow keys work in the top dropdown menu, but don't work
in other dropdown menus on the same page.
|
|
|
|
|
|
|
|
This allows removing a `mut` which is nicer.
Suggested-by: @jyn514
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
|
|
* Remove a needless comma in the Rust code
* Replace double spaces after full stops with single spaces
Requested-by: @GuillaumeGomez
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
This is a fairly simple special case of --default-eetting. We must
set both "theme" and "use-system-theme".
Providing it separately enables us to document a way to set the theme
without expoosing the individual settings keywords, which are quite
complex.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
We just plumb through what the user tells us.
This is flagged as unstable, mostly because I don't understand the
compatibility rules that rustdoc obeys for local storage data, and how
error handling of invalid data works.
We collect() the needed HashMap from Vec of Vecs of (key, value)
pairs, so that there is a nice place to add new more-specific options.
It would have been possible to use Extend::extend but doing it this
way ensures that all the used inputs are (and will stay) right next to
each other.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
rustdoc has various user-configurable preferences. These are recorded
in web Local Storage (where available). But we want to provide a way
to configure the default default, including for when web storage is
not available.
getSettingValue is the function responsible for looking up these
settings. Here we make it fall back some in-DOM data, which
ultimately comes from RenderOptions.default_settings.
Using HTML data atrtributes is fairly convenient here, dsspite the
need to transform between snake and kebab case to avoid the DOM
converting kebab case to camel case (!)
We cache the element and dataset lookup in a global variable, to
ensure that getSettingValue remains fast.
The DOM representation has to be in an element which precedes the
inclusion of storage.js. That means it has to be in the <head> and we
should not use an empty <div> as the container (although most browsers
will accept that). An empty <script> element provides a convenient
and harmless container object. <meta> would be another possibility
but runs a greater risk of having unwanted behaviours on weird
browsers.
We trust the RenderOptions not to contain unhelpful setting names,
which don't fit nicely into an HTML attribute. It's awkward to quote
dataset keys.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
Currently, storage.js and main.js have many open-coded calls to
getCurrentValue for "rustdoc-" values, but these are settings and
should be handled by getSettingValue.
So make getSettingValue part of storage.js (where everyone can call
it) and use it everywhere.
No functional change yet. We are going to make getSettingValue do
something more sophisticated in a moment.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
Make some functions private that don't have to be public
r? @GuillaumeGomez
|
|
|
|
|