about summary refs log tree commit diff
path: root/src/test/rustdoc
AgeCommit message (Collapse)AuthorLines
2019-11-13Auto merge of #66211 - kinnison:kinnison/fix-66159, r=GuillaumeGomezbors-0/+12
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
2019-11-08rustdoc: Deliberately load extern crates before processing docsDaniel Silverstone-0/+12
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>
2019-11-07Add more --extern tests.Eric Huss-1/+1
2019-11-01Rollup merge of #65857 - kinnison:kinnison/issue-55364, ↵Tyler Mandry-0/+88
r=Manisheart,GuillaumeGomez 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
2019-10-31rustdoc: Resolve module-level doc references more locallyDaniel Silverstone-0/+88
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>
2019-10-29stabilize cfg(doctest)Guillaume Gomez-2/+0
2019-10-22Fix rustdoc const generics testvarkor-0/+1
2019-10-21Rollup merge of #65314 - tmiasko:rustdoc-z, r=ollie27Mazdak Farrokhzad-0/+17
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.
2019-10-19privacy: Avoid one more `unwrap` causing an ICE in rustdocVadim Petrochenkov-0/+9
The issue is rustdoc-specific because its root cause if the `everybody_loops` pass makes some def-ids to not have local hir-ids
2019-10-11rustdoc: forward -Z options to rustcTomasz Miąsko-0/+17
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.
2019-09-28rustc: rely on c_variadic == true instead of CVarArgs in HIR/Ty fn signatures.Eduard-Mihai Burtescu-1/+1
2019-09-27Auto merge of #63937 - Nashenas88:rustdoc_57180, r=GuillaumeGomezbors-0/+23
Fix ICE in rustdoc when merging generic and where bounds of an Fn with an output Fixes #57180
2019-09-25Rollup merge of #64599 - csmoe:doc_async_reexport, r=nikomatsakisMazdak Farrokhzad-1/+19
Rustdoc render async function re-export Closes #63710 r? @nikomatsakis
2019-09-21add rustdoc test for async fn reexportcsmoe-1/+19
2019-09-17Generate proc macro harness in AST order.Aaron Hill-1/+12
This ensures that we match the order used by proc macro metadata serialization. Fixes #64251
2019-09-05Rollup merge of #63930 - estebank:rustdoc-ice, r=GuillaumeGomezMazdak Farrokhzad-0/+32
Account for doc comments coming from proc macros without spans Fix https://github.com/rust-lang/rust/issues/63821.
2019-08-29Rollup merge of #62734 - GuillaumeGomez:hide-default-methods, r=Mark-SimulacrumMazdak Farrokhzad-9/+9
Hide trait default methods Fixes #62499. However, the question remains: do we want to extend it to this point or not? r? @QuietMisdreavus
2019-08-29Auto merge of #62855 - Aaron1011:feature/rustdoc-reexport-final, r=petrochenkovbors-10/+20
Improve Rustdoc's handling of procedural macros Fixes #58700 Fixes #58696 Fixes #49553 Fixes #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.
2019-08-28Add regression test for issue, apply suggestion to convert to assert_eqPaul Daniel Faria-0/+23
2019-08-26add regression testEsteban Küber-0/+32
2019-08-25Auto merge of #61613 - sinkuu:impl_trait_inline, r=ollie27bors-0/+50
Support `impl Trait` in inlined documentation `impl Trait` in argument position was not properly rendered when inlined from other crates. ([a live example on docs.rs](https://docs.rs/libp2p/0.8.1/libp2p/floodsub/struct.Floodsub.html#method.unsubscribe)) ![old](https://user-images.githubusercontent.com/7091080/59089838-14ba9900-8946-11e9-830b-53b317bdecb4.png) ↓ ![new](https://user-images.githubusercontent.com/7091080/59089844-16845c80-8946-11e9-9fe3-8998af9d73ce.png)
2019-08-24Improve Rustdoc's handling of procedural macrosAaron Hill-10/+20
Fixes #58700 Fixes #58696 Fixes #49553 Fixes #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.
2019-08-20Remove async_await gates from tests.Mazdak Farrokhzad-9/+2
2019-08-19Fix ICE with `impl Trait` in type boundsShotaro Yamada-0/+8
2019-08-19Fix tidyShotaro Yamada-2/+6
2019-08-19Support nested `impl Trait`Shotaro Yamada-0/+8
2019-08-19Associated type bound for inlined impl Trait docShotaro Yamada-0/+10
2019-08-19Support `impl Trait` in inlined documentationShotaro Yamada-0/+20
2019-08-06Rollup merge of #62821 - GuillaumeGomez:not-listed-methods, r=Mark-SimulacrumMazdak Farrokhzad-0/+29
Not listed methods Fixes #60326. cc @rust-lang/rustdoc r? @QuietMisdreavus
2019-08-06Add test for DerefMut methodsGuillaume Gomez-0/+29
2019-08-04Auto merge of #63048 - Aaron1011:feature/rustdoc-reexport-doc, r=GuillaumeGomezbors-0/+13
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.
2019-08-01Rollup merge of #62971 - GuillaumeGomez:keyword-sidebar, r=nobodyPietro Albini-0/+1
Add keywords item into the sidebar Fixes #62939. cc @pravic screenshot of the result: ![Screenshot from 2019-07-25 14-29-48](https://user-images.githubusercontent.com/3050060/61874545-f9512080-aee8-11e9-8e8b-aa50216aec94.png) r? @QuietMisdreavus
2019-07-27Use doc comments from 'pub use' statementsAaron Hill-0/+13
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.
2019-07-26Introduce built-in macros through libcoreVadim Petrochenkov-0/+3
2019-07-25Add keywords item into the sidebarGuillaume Gomez-0/+1
2019-07-16Update testsGuillaume Gomez-9/+9
2019-07-11Remove `MacroKind::ProcMacroStub`Vadim Petrochenkov-1/+1
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.
2019-07-09Rollup merge of #62450 - nagisa:reclimit, r=pnkfelixMazdak Farrokhzad-0/+104
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
2019-07-06rustdoc: set cfg(doctest) when collecting doctestsQuietMisdreavus-0/+8
2019-07-07Raise the default recursion limit to 128Simonas Kazlauskas-0/+104
2019-07-04Permit use of mem::uninitialized via allow(deprecated)Mark Rousskov-0/+1
2019-07-01Revert "implicit `Option`-returning doctests"Guillaume Gomez-12/+0
This reverts commit 6bb6c001be34d0932a014df981ee18f165c43374.
2019-06-20rustdoc: generate implementors for all auto traitsSimonas Kazlauskas-3/+15
Previously we would only generate a list of synthetic implementations for two well known traits – Send and Sync. With this patch all the auto traits known to rustc are considered. This includes such traits like Unpin and user’s own traits. Sadly the implementation still iterates through the list of crate items and checks them against the traits, which for non-std crates containing their own auto-traits will still not include types defined in std/core. It is an improvement nontheless.
2019-06-07Fix slice const generic length displayGuillaume Gomez-0/+12
2019-06-01Rollup merge of #61263 - GuillaumeGomez:valid-html, r=ManishearthMazdak Farrokhzad-3/+3
Don't generate div inside header (h4/h3/h...) elements Fixes #60865. According to the HTML spec, we're not supposed to put `div` elements inside heading elements (h4/h3/h...). It doesn't change the display as far as I could tell. r? @QuietMisdreavus
2019-05-30Rollup merge of #61279 - llogiq:implicit-option-main-doctests, r=GuillaumeGomezMazdak Farrokhzad-0/+12
implicit `Option`-returning doctests This distinguishes `Option` and `Result`-returning doctests with implicit `main` method, where the former tests must end with `Some(())`. Open question: Does this need a feature gate? r? @GuillaumeGomez
2019-05-30Rollup merge of #60802 - euclio:pulldown-cmark-panic, r=GuillaumeGomezMazdak Farrokhzad-0/+9
upgrade rustdoc's `pulldown-cmark` to 0.5.2 Fixes #60482.
2019-05-29upgrade rustdoc's `pulldown-cmark` to 0.5.2Andy Russell-0/+9
Fixes #60482.
2019-05-29Don't generate div inside header (h4/h3/h...) elementsGuillaume Gomez-3/+3
2019-05-28Add a regression test for unevaluated const in rustdocvarkor-0/+21
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-09-29 00:36:51 +0000