summary refs log tree commit diff
path: root/src/librustdoc/clean/inline.rs
AgeCommit message (Collapse)AuthorLines
2019-12-02syntax: Use `ast::MacArgs` for macro definitionsVadim Petrochenkov-1/+1
2019-11-28rustc_metadata: Merge `cstore.rs` into `creader.rs`Vadim Petrochenkov-1/+1
2019-10-27rustc, rustc_passes: don't depend on syntax_expand.Mazdak Farrokhzad-1/+1
This is done by moving some data definitions to syntax::expand.
2019-10-24Turn crate store into a resolver outputVadim Petrochenkov-2/+2
2019-10-18Rollup merge of #65535 - eddyb:sliced-predicates, r=nikomatsakisTyler Mandry-7/+7
rustc: arena-allocate the slice in `ty::GenericsPredicate`, not the whole struct. While rebasing #59789 I noticed we can do this now. However, it doesn't help much without changing `inferred_outlives_of` to the same type, which I might try next.
2019-10-18rustc: arena-allocate the slice in `ty::GenericsPredicate`, not the whole ↵Eduard-Mihai Burtescu-7/+7
struct.
2019-10-16move syntax::ext to new crate syntax_expandMazdak Farrokhzad-1/+1
2019-09-26Rename `Item.node` to `Item.kind`varkor-3/+3
2019-09-25Rollup merge of #64599 - csmoe:doc_async_reexport, r=nikomatsakisMazdak Farrokhzad-2/+2
Rustdoc render async function re-export Closes #63710 r? @nikomatsakis
2019-09-21rename is_async_fn to asyncnesscsmoe-5/+1
2019-09-19append asyncness info to functionscsmoe-2/+6
2019-09-13Unwrap Visibility fieldsMark Rousskov-2/+2
There's not really any reason to not have the visibility default to inherited, and this saves us the trouble of checking everywhere for whether we have a visibility or not.
2019-08-29Auto merge of #62855 - Aaron1011:feature/rustdoc-reexport-final, r=petrochenkovbors-8/+10
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-24Improve Rustdoc's handling of procedural macrosAaron Hill-8/+10
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-19Support `impl Trait` in inlined documentationShotaro Yamada-3/+6
2019-08-11Use a HashSet instead of VecMark Rousskov-5/+3
2019-08-11Remove ReentrantMutexMark Rousskov-4/+2
This drops the parking_lot dependency; the ReentrantMutex type appeared to be unused (at least, no compilation failures occurred). This is technically a possible change in behavior of its users, as lock() would wait on other threads releasing their guards, but since we didn't actually remove any threading or such in this code, it appears that we never used that behavior (the behavior change is only noticeable if the type previously was used in two threads, in a single thread ReentrantMutex is useless).
2019-08-11Remove crate_name from DocContextMark Rousskov-4/+1
tcx.crate_name is the appropriate way to retrieve the crate name.
2019-08-10Replace is_doc_reachable with is_publicMark Rousskov-3/+3
2019-07-27Use doc comments from 'pub use' statementsAaron Hill-15/+43
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-06-18syntax: Factor out common fields from `SyntaxExtension` variantsVadim Petrochenkov-9/+3
2019-06-17remove _by_hir_id if there is no NodeId counterpartljedrz-2/+2
2019-06-10syntax: Rename variants of `SyntaxExtension` for consistencyVadim Petrochenkov-1/+1
2019-05-13Pass a `Symbol` to `check_name`, `emit_feature_err`, and related functions.Nicholas Nethercote-1/+2
2019-05-03rustc: rename hir::def::Def to Res (short for "resolution").Eduard-Mihai Burtescu-26/+25
2019-05-03rustc: factor most DefId-containing variants out of Def and into DefKind.Eduard-Mihai Burtescu-15/+15
2019-04-21Remove mutability from `Def::Static`Vadim Petrochenkov-2/+2
2019-03-31Fix invalid bounds string generation in rustdocGuillaume Gomez-5/+5
2019-03-26Rollup merge of #59004 - GuillaumeGomez:generics-handling, r=QuietMisdreavusGuillaume Gomez-3/+8
[rustdoc] Improve "in parameters" search and search more generally Fixes #58230. r? @QuietMisdreavus
2019-03-24Separate variant id and variant constructor id.David Wood-3/+1
This commit makes two changes - separating the `NodeId` that identifies an enum variant from the `NodeId` that identifies the variant's constructor; and no longer creating a `NodeId` for `Struct`-style enum variants and structs. Separation of the variant id and variant constructor id will allow the rest of RFC 2008 to be implemented by lowering the visibility of the variant's constructor without lowering the visbility of the variant itself. No longer creating a `NodeId` for `Struct`-style enum variants and structs mostly simplifies logic as previously this `NodeId` wasn't used. There were various cases where the `NodeId` wouldn't be used unless there was an unit or tuple struct or enum variant but not all uses of this `NodeId` had that condition, by removing this `NodeId`, this must be explicitly dealt with. This change mostly applied cleanly, but there were one or two cases in name resolution and one case in type check where the existing logic required a id for `Struct`-style enum variants and structs.
2019-03-21Add bounds for return types as wellGuillaume Gomez-1/+2
2019-03-21Greatly improve generics handling in rustdoc searchGuillaume Gomez-3/+7
2019-03-10Make the rustc driver and interface demand drivenJohn Kåre Alsaker-19/+19
2019-03-07HirIdification: replace NodeId method callsljedrz-2/+2
2019-02-24Auto merge of #58232 - ljedrz:HirIdification_continued, r=Zoxcbors-4/+4
HirId-ify intravisit A big step towards https://github.com/rust-lang/rust/pull/57578. This affects mostly `hir::{collector, intravisit}` and `rustc::lint`.
2019-02-23Fix tidy check errorsHirokazu Hata-2/+11
2019-02-23Transition librustdoc to 2018 editionHirokazu Hata-22/+22
2019-02-20HirIdification: change some NodeId to HirId callsljedrz-4/+4
2019-02-01don't try to get a DefId for a Def that doesn't have oneQuietMisdreavus-2/+5
2018-12-25Remove licensesMark Rousskov-10/+0
2018-12-18Don't render const keyword on stableGuillaume Gomez-1/+1
2018-12-06Use a function to access the Hir map to be able to turn it into a query laterJohn Kåre Alsaker-7/+7
2018-10-19Prefer `Default::default` over `FxHash*::default` in struct constructorsOliver Scherer-1/+1
2018-10-19Deprecate the `FxHashMap()` and `FxHashSet()` constructor function hackOliver Scherer-1/+1
2018-09-26add derive macros' helper attributes to doc outputQuietMisdreavus-1/+7
2018-09-25disable proc-macro re-export inliningQuietMisdreavus-7/+8
Proc-macros don't emit their attributes or source spans across crates. This means that rustdoc can't actually see the docs of a proc-macro if it wasn't defined in the active crate, and attempting to inline it creates an empty page with no docs or source link. In lieu of attempting to fix that immediately, this commit forces proc-macro re-exports to never inline, which at least creates usable links to complete documentation.
2018-09-25handle proc-macros as macros instead of functionsQuietMisdreavus-31/+34
2018-09-20shuffle ownership of `external_traits`QuietMisdreavus-4/+10
constraints: - clean/inline.rs needs this map to fill in traits when inlining - fold.rs needs this map to allow passes to fold trait items - html/render.rs needs this map to seed the Cache.traits map of all known traits The first two are the real problem, since `DocFolder` only operates on `clean::Crate` but `clean/inline.rs` only sees the `DocContext`. The introduction of early passes means that these two now exist at the same time, so they need to share ownership of the map. Even better, the use of `Crate` in a rustc thread pool means that it needs to be Sync, so it can't use `Lrc<Lock>` to manually activate thread-safety. `parking_lot` is reused from elsewhere in the tree to allow use of its `ReentrantMutex`, as the relevant parts of rustdoc are still single-threaded and this allows for easier use in that context.
2018-09-20refactor: move `access_levels` into RenderInfoQuietMisdreavus-2/+2
2018-09-20collect auto-/blanket-impls during collect-trait-implsQuietMisdreavus-21/+7
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-10 21:36:19 +0000