rustdoc: Stabilize `edition` annotation.
The rustdoc `edition` annotation is currently ignored on stable. This means that the tests will be ignored, unless there is a `rust` annotation, then it will use the global edition. I suspect this was just an oversight during the edition stabilization, but I don't know. Example:
```rust
/// ```edition2018
/// // This code block was ignored on stable.
/// ```
/// ```rust,edition2018
/// // This code block would use whatever edition is passed on the command line.
/// ```
```
AFAIK, it is not possible to write a test that verifies stable behavior, as all tests appear to set RUSTC_BOOTSTRAP which forces all tests to run as "nightly", even on a stable release.
Closes#65980
Fix ICE when documentation includes intra-doc-link
When collecting intra-doc-links we could trigger the loading of extra crates into the crate store due to name resolution finding crates referred to in documentation but not in code. This might be due to
configuration differences or simply referring to something else.
This would cause an ICE because the newly loaded crate metadata existed in a crate store associated with the rustdoc global context, but the resolver had its own crate store cloned just before the documentation processing began and as such it could try and look up crates in a store which lacked them.
In this PR, I add support for `--extern-private` to the `rustdoc` tool so that it is supported for `compiletest` to then pass the crates in; and then I fix the issue by forcing the resolver to look over all the crates before we then lower the input ready for processing into documentation.
The first commit (the `--extern-private`) could be replaced with a commit which adds support for `--extern` to `compiletest` if preferred, though I think that adding `--extern-private` to `rustdoc` is more useful anyway since it makes the CLI a little more like `rustc`'s which might help reduce surprise for someone running it by hand or in their own test code.
The PR is meant to fix#66159 though it may also fix#65840.
cc @GuillaumeGomez
In order that we can successfully later resolve paths in crates
which weren't loaded as a result of merely parsing the crate
we're documenting, we force the resolution of the path to each
crate before cloning the resolver to use later. Closes#66159
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
rustdoc: Resolve module-level doc references more locally
Module level docs should resolve intra-doc links as locally as
possible. As such, this commit alters the heuristic for finding
intra-doc links such that we attempt to resolve names mentioned
in *inner* documentation comments within the (sub-)module rather
that from the context of its parent.
I'm hoping that this fixes#55364 though right now I'm not sure it's the right fix.
r? @GuillaumeGomez
Module level docs should resolve intra-doc links as locally as
possible. As such, this commit alters the heuristic for finding
intra-doc links such that we attempt to resolve names mentioned
in *inner* documentation comments within the (sub-)module rather
that from the context of its parent.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
rustdoc: forward -Z options to rustc
Currently rustdoc does not forward `-Z` options to rustc when building
test executables. This makes impossible to use rustdoc to run test
samples when crate under test is instrumented with one of sanitizers
`-Zsanitizer=...`, since the final linking step will not include
sanitizer runtime library.
Forward `-Z` options to rustc to solve the issue.
Helps with #43031.
Currently rustdoc does not forward `-Z` options to rustc when building
test executables. This makes impossible to use rustdoc to run test
samples when crate under test is instrumented with one of sanitizers
`-Zsanitizer=...`, since the final linking step will not include
sanitizer runtime library.
Forward `-Z` options to rustc to solve the issue.
Helps with #43031.
Improve Rustdoc's handling of procedural macros
Fixes#58700Fixes#58696Fixes#49553Fixes#52210
This commit removes the special rustdoc handling for proc macros, as we can now
retrieve their span and attributes just like any other item.
A new command-line option is added to rustdoc: `--crate-type`. This takes the same options as rustc's `--crate-type` option. However, all values other than `proc-macro` are treated the same. This allows Rustdoc to enable 'proc macro mode' when handling a proc macro crate.
In compiletest, a new 'rustdoc-flags' option is added. This allows us to
pass in the '--proc-macro-crate' flag in the absence of Cargo.
I've opened [an additional PR to Cargo](https://github.com/rust-lang/cargo/pull/7159) to support passing in this flag.
These two PRS can be merged in any order - the Cargo changes will not
take effect until the 'cargo' submodule is updated in this repository.
Fixes#58700Fixes#58696Fixes#49553Fixes#52210
This commit removes the special rustdoc handling for proc macros, as we
can now
retrieve their span and attributes just like any other item.
A new command-line option is added to rustdoc: `--crate-type`. This
takes the same options as rustc's `--crate-type` option. However, all
values other than `proc-macro` are treated the same. This allows Rustdoc
to enable 'proc macro mode' when handling a proc macro crate.
In compiletest, a new 'rustdoc-flags' option is added. This allows us to
pass in the '--proc-macro-crate' flag in the absence of Cargo.
I've opened [an additional PR to
Cargo](https://github.com/rust-lang/cargo/pull/7159) to support passing
in this flag.
These two PRS can be merged in any order - the Cargo changes will not
take effect until the 'cargo' submodule is updated in this repository.
Use doc comments from 'pub use' statements
Split off from #62855
Currently, rustdoc ignores any doc comments found on 'pub use'
statements. As described in issue #58700, this makes it impossible to
properly document procedural macros. Any doc comments must be written on
the procedural macro definition, which must occur in a dedicated
proc-macro crate. This means that any doc comments or doc tests cannot
reference items defined in re-exporting crate, despite the fact that
such items may be required to use the procedural macro.
To solve this issue, this commit allows doc comments to be written on
'pub use' statements. For consistency, this applies to *all* 'pub use'
statements, not just those importing procedural macros.
When inlining documentation, documentation on 'pub use' statements will
be prepended to the documentation of the inlined item. For example,
the following items:
```rust
mod other_mod {
/// Doc comment from definition
pub struct MyStruct;
}
/// Doc comment from 'pub use'
///
pub use other_mod::MyStruct;
```
will caues the documentation for the re-export of 'MyStruct' to be
rendered as:
```
Doc comment from 'pub use'
Doc comment from definition
```
Note the empty line in the 'pub use' doc comments - because doc comments
are concatenated as-is, this ensure that the doc comments on the
definition start on a new line.
Split off from #62855
Currently, rustdoc ignores any doc comments found on 'pub use'
statements. As described in issue #58700, this makes it impossible to
properly document procedural macros. Any doc comments must be written on
the procedural macro definition, which must occur in a dedicated
proc-macro crate. This means that any doc comments or doc tests cannot
reference items defined in re-exporting crate, despite the fact that
such items may be required to use the procedural macro.
To solve this issue, this commit allows doc comments to be written on
'pub use' statements. For consistency, this applies to *all* 'pub use'
statements, not just those importing procedural macros.
When inlining documentation, documentation on 'pub use' statements will
be prepended to the documentation of the inlined item. For example,
the following items:
```rust
mod other_mod {
/// Doc comment from definition
pub struct MyStruct;
}
/// Doc comment from 'pub use'
///
pub use other_mod::MyStruct;
```
will caues the documentation for the re-export of 'MyStruct' to be
rendered as:
```
Doc comment from 'pub use'
Doc comment from definition
```
Note the empty line in the 'pub use' doc comments - because doc comments
are concatenated as-is, this ensure that the doc comments on the
definition start on a new line.
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.
Raise the default recursion limit to 128
The previous limit of 64 is being (just) barely hit by genuine code out there, which is causing issues like https://github.com/rust-lang/rust/issues/62059 to rear their end.
Ideally, we wouldn’t have such arbitrary limits at all, but while we do, it makes a lot of sense to just raise this limit whenever genuine use-cases end up hitting it.
r? @pnkfelix
Fixes https://github.com/rust-lang/rust/issues/62059
