improve folder name for persistent doc tests
This fixes#69411, by using the entire path as folder name and storing already visited paths in a HashMap + appending a number to the file name for duplicates.
use is_empty() instead of len comparison (clippy::len_zero)
use if let instead of while let loop that never loops (clippy::never_loop)
remove redundant returns (clippy::needless_return)
remove redundant closures (clippy::redundant_closure)
use if let instead of match and wildcard pattern (clippy::single_match)
don't repeat field names redundantly (clippy::redundant_field_names)
Create output dir in rustdoc markdown render
`rustdoc` command on a standalone markdown document fails because the output directory (which default to `doc/`) is not created, even when specified with the `--output` argument.
This PR adds the creation of the output directory before the file creation to avoid an unexpected error which is unclear.
I am not sure about the returned error code. I did not find a table explaining them. So I simply put the same error code that is returned when `File::create` fails because they are both related to file-system errors.
Resolve#70431
Tweak output for invalid negative impl errors
Follow up to #69722. Tweak negative impl errors emitted in the HIR:
```
error[E0192]: invalid negative impl
--> $DIR/E0192.rs:9:6
|
LL | impl !Trait for Foo { }
| ^^^^^^
|
= note: negative impls are only allowed for auto traits, like `Send` and `Sync`
```
couple more clippy fixes (let_and_return, if_same_then_else)
* summarize if-else-code with identical blocks (clippy::if_same_then_else)
* don't create variable bindings just to return the bound value immediately (clippy::let_and_return)
Extend search
I realized that when looking for "struct:String" in the rustdoc search for example, the "in arguments" and "returned" tabs were always empty. After some investigation, I realized it was because we only provided the name, and not the type, making it impossible to pass the "type filtering" check.
To resolve this, I added the type alongside the name. Note for the future: we could improve this by instead only registering the path id and use the path dictionary directly. The only problem with that solution (which I already tested) is that it becomes complicated for types in other crates. It'd force us to handle both case with an id and a case with `(name, type)`. I found the current PR big enough to not want to provide it directly. However, I think this is definitely worth it to make it work this way in the future.
About the two tests I added: they don't have much interest except checking that we actually have something returned in the search in the cases of a type filtering with and without literal search.
I also had to update a bit the test script to add the new locally global (haha) variable I created (`NO_TYPE_FILTER`). I added this variable to make the code easier to read than just "-1".
r? @kinnison
cc @ollie27
Remove some imports to the rustc crate
- When we have `NestedVisitorMap::None`, we use `type Map = dyn intravisit::Map<'v>;` instead of the actual map. This doesn't actually result in dynamic dispatch (in the future we may want to use an associated type default to simplify the code).
- Use `rustc_session::` imports instead of `rustc::{session, lint}`.
r? @Zoxc
Use `pprust` to print attributes in rustdoc
Fixes https://github.com/rust-lang/rust/issues/69559.
I'm not sure what the original motivation was for the `render_attribute`, so I may be missing something, but replacing it with `pprust::attribute_to_string` seems to give the intended output (modulo some spacing idiosyncrasies).
r? @GuillaumeGomez
ast: `Mac`/`Macro` -> `MacCall`
It's now obvious that these refer to macro calls rather than to macro definitions.
It's also a single name instead of two different names in different places.
`rustc_expand` usually calls macro calls in a wide sense (including attributes and derives) "macro invocations", but structures and variants renamed in this PR are only relevant to fn-like macros, so it's simpler and clearer to just call them calls.
cc https://github.com/rust-lang/rust/pull/63586#discussion_r314232513
r? @eddyb
