I left some of them so this change doesn't balloon in size and because
removing the RefCell in `DocContext.resolver` would require compiler
changes.
Thanks to `@jyn514` for making this a lot easier with #82020!
[intra-doc links] Don't check feature gates of items re-exported across crates
It should be never break another crate to re-export a public item.
Note that this doesn't check the feature gate at
*all* for other crates:
- Feature-gates aren't currently serialized, so the only way to check
the gate is with ad-hoc attribute checking.
- Checking the feature gate twice (once when documenting the original
crate and one when documenting the current crate) seems not great.
This should still catch using the feature most of the time though, since
people tend to document their own crates.
Closes https://github.com/rust-lang/rust/issues/82284.
r? `@Manishearth`
Before:
The Rust Standard LibraryThe Rust Standard Library is the foundation of portable Rust software, a set of minimal and battle-tested shared abstractions for the broader Rust ecosystem. It offers core types, like `Vec<T>` and `Option<T>`, library-defined operations on language primitives, standard macros, I/O and multithreading, among many other things.
After:
The Rust Standard Library
Make `Clean` take &mut DocContext
- Take `FnMut` in `rustc_trait_selection::find_auto_trait_generics`
- Take `&mut DocContext` in most of `clean`
- Collect the iterator in auto_trait_impls instead of iterating lazily; the lifetimes were really bad.
This combined with https://github.com/rust-lang/rust/pull/82018 should hopefully help with https://github.com/rust-lang/rust/pull/82014 by allowing `cx.cache.exported_traits` to be modified in `register_res`. Previously it had to use interior mutability, which required either adding a RefCell to `cache.exported_traits` on *top* of the existing `RefCell<Cache>` or mixing reads and writes between `cx.exported_traits` and `cx.cache.exported_traits`. I don't currently have that working but I expect it to be reasonably easy to add after this.
It should be never break another crate to re-export a public item.
Note that this doesn't check the feature gate at
*all* for other crates:
- Feature-gates aren't currently serialized, so the only way to check
the gate is with ad-hoc attribute checking.
- Checking the feature gate twice (once when documenting the original
crate and one when documenting the current crate) seems not great.
This should still catch using the feature most of the time though, since
people tend to document their own crates.
rustdoc: Support argument files
Factors out the `rustc_driver` logic that handles argument files so that rustdoc supports them as well, e.g.:
rustdoc `@argfile`
This is needed to be able to generate docs for projects that already use argument files when compiling them, e.g. projects that pass a huge number of `--cfg` arguments.
The feature was stabilized for `rustc` in #66172.
Factors out the `rustc_driver` logic that handles argument files
so that rustdoc supports them as well, e.g.:
rustdoc @argfile
This is needed to be able to generate docs for projects that
already use argument files when compiling them, e.g. projects
that pass a huge number of `--cfg` arguments.
The feature was stabilized for `rustc` in #66172.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
- Take `FnMut` in `rustc_trait_selection::find_auto_trait_generics`
- Take `&mut DocContext` in most of `clean`
- Collect the iterator in auto_trait_impls instead of iterating lazily; the lifetimes were really bad.
- Changes `fn sess` to properly return a borrow with the lifetime of `'tcx`, not the mutable borrow.
Only store a LocalDefId in some HIR nodes
Some HIR nodes are guaranteed to be HIR owners: Item, TraitItem, ImplItem, ForeignItem and MacroDef.
As a consequence, we do not need to store the `HirId`'s `local_id`, and we can directly store a `LocalDefId`.
This allows to avoid a bit of the dance with `tcx.hir().local_def_id` and `tcx.hir().local_def_id_to_hir_id` mappings.
avoid full-slicing slices
If we already have a slice, there is no need to get another full-range slice from that, just use the original.
clippy::redundant_slicing
Fix ES5 errors (IE11)
rustdoc is supposed to run on IE11 but someone reported me that it wasn't. I just confirmed it by using `es-check` with the `es5` option like this:
```
$ es-check es5 src/librustdoc/html/static/*.js
```
The PR fixes those issues and add CI checks to prevent regressions.
`@Mark-Simulacrum:` I added checks in the CI, but not sure if it's the correct way to do it. Any help on that side would be very appreciated!
r? `@Nemo157`
[rustdoc-json] Make `header` a vec of modifiers, and FunctionPointer consistent
Bumps version number and adds tests, this is a breaking change. I can split this into two (`is_unsafe` -> `header` and `header: Vec<Modifiers>`) if desired.
Rationale: Modifiers are individual notes on a function, it makes more sense for them to be a list of an independent enum over a String which is inconsistently exposing the HIR representation (prefix_str vs custom literals).
Function pointers currently only support `unsafe`, but there has been talk on and off about allowing them to also support `const`, and this makes handling their modifiers consistent with handling those of a function, allowing better shared code.
`@rustbot` modify labels: +A-rustdoc-json +T-rustdoc
CC: `@HeroicKatora`
r? `@jyn514`
Refactor `get_word_attr` to return only `Option`
This commit removes `bool` from the return type of `NestedAttributesExt::get_word_attr` so it will return only `Option<ast::NestedMetaItem>` for less redundancy.
Closes#82016
r? `@jyn514`
Fix private intra-doc warnings on associated items
The issue was that the `kind, id` override was previously only being
considered for the disambiguator check, not the privacy check. This uses
the same ID for both.
Fixes https://github.com/rust-lang/rust/issues/81981.
r? ``@max-heller``
clean up clean::Static struct
Having a `String` for the expression didn't make much sense, and even less when it's actually not used (except in json so I kept it).
r? ``@jyn514``
The issue was that the `kind, id` override was previously only being
considered for the disambiguator check, not the privacy check. This uses
the same ID for both.
Unfortunately, this can't currently be tested. The problem is that we
need the file to be compiled first to then be used as dependency, which
cannot be done currently unfortunately in the rustdoc test suites.
Example:
```rust
// name this file "foo.rs"
/// ```
/// let x = foo::foo();
/// ```
pub fn foo() {}
```
If you run `rustdoc --test foo.rs`, you'll get:
```
running 1 test
test foo.rs - foo (line 1) ... FAILED
failures:
---- foo.rs - foo (line 1) stdout ----
error[E0463]: can't find crate for `foo`
--> foo.rs:0:1
|
2 | extern crate foo;
| ^^^^^^^^^^^^^^^^^ can't find crate
```
If a test were possible, it would look something like
````rust
#![crate_name = "mod"]
#![crate_type = "lib"]
//! ```
//! // NOTE: requires that the literal string 'mod' appears in the doctest for
//! // the bug to appear
//! assert_eq!(1, 1);
//! ```
````
