rustdoc: stabilise --default-theme command line option
As discussed in #77213, this seems like it has bedded in and can be safely and usefully made stable.
(rustdoc already has other stable options that interact quite intimately with the rustdoc-supplied CSS, and also an option for supplying entirely different CSS, so exposing the theme names this way seems a very minor step.)
There is also a commit to do some minor grammar fixes to the help message.
[rustdoc] Calculate span information on demand instead of storing it ahead of time
This brings `size_of<clean::types::Span>()` down from over 100 bytes (!!) to only 12, the same as rustc. It brings `Item` down even more, from `784` to `680`.
~~TODO: I need to figure out how to do this for the JSON backend too. That uses `From` impls everywhere, which don't allow passing in the `Session` as an argument. `@P1n3appl3,` `@tmandry,` maybe one of you have ideas?~~ Figured it out, fortunately only two functions needed to be changed. I like the `convert_x()` format better than `From` everywhere but I'm open to feedback.
Helps with #79103
As discussed in #77213, this seems like it has bedded in and can be
safely and usefully made stable.
(rustdoc already has other stable options that interact quite
intimately with the rustdoc-supplied CSS, and also an option for
supplying entirely different CSS, so exposing the theme names this way
seems a very minor step.)
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Rustdoc check option
The ultimate goal behind this option would be to have `rustdoc --check` being run when you use `cargo check` as a second step.
r? `@jyn514`
* 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>
The contents of the generics will be mostly ignored (except for warning
if fully-qualified syntax is used, which is currently unsupported in
intra-doc links - see issue #74563).
* Allow links like `Vec<T>`, `Result<T, E>`, and `Option<Box<T>>`
* Allow links like `Vec::<T>::new()`
* Warn on
* Unbalanced angle brackets (e.g. `Vec<T` or `Vec<T>>`)
* Missing type to apply generics to (`<T>` or `<Box<T>>`)
* Use of fully-qualified syntax (`<Vec as IntoIterator>::into_iter`)
* Invalid path separator (`Vec:<T>:new`)
* Too many angle brackets (`Vec<<T>>`)
* Empty angle brackets (`Vec<>`)
Note that this implementation *does* allow some constructs that aren't
valid in the actual Rust syntax, for example `Box::<T>new()`. That may
not be supported in rustdoc in the future; it is an implementation
detail.
This modules contains the implementation of doctests, and not the
tests of rustdoc itself. This name is confusing, so let's rename it to
doctest for clarity.
`run()` returns `Result<(), String>`. But on failure it always returns
an empty string, and then `wrap_return()` treats an empty string
specially, by not reporting the error.
It turns out we already have the `ErrorReported` type for this sort of
behaviour. This commit changes `run()` to use it.
rustdoc's `main()` immediately spawns a thread, M, with a large stack
(16MiB or 32MiB) on which it runs `main_args()`. `main_args()` does a
small amount of options processing and then calls
`setup_callbacks_and_run_in_default_thread_pool_with_globals()`, which
spawns it own thread, and M is not used further.
So, thread M seems unnecessary. However, it does serve a purpose: if the
options processing in `main_args()` panics, that panic is caught when M
is joined. So M can't simply be removed.
However, `main_options()`, which is called by `main_args()`, has a
`catch_fatal_errors()` call within it. We can move that call to `main()`
and change it to the very similar `catch_with_exit_code()`. With that in
place, M can be removed, and panics from options processing will still
be caught appropriately.
Even better, this makes rustdoc's `main()` match rustc's `main()`, which
also uses `catch_with_exit_code()`.
(Also note that the use of a 16MiB/32MiB stack was eliminated from rustc
in #55617.)
