[rustdoc] Move doc cfg propagation pass before items stripping passes #147153
Conversation
rustbot
added
S-waiting-on-review
GuillaumeGomez
changed the title
This comment has been minimized.
This comment has been minimized.
GuillaumeGomez
force-pushed
the
doc-propagation-before-stripping-items
branch
from
9157004 to
a5068f7
Compare
This comment has been minimized.
This comment has been minimized.
GuillaumeGomez
force-pushed
the
doc-propagation-before-stripping-items
branch
from
a5068f7 to
9119eba
Compare
|
This just made me realize that the way we print feature dependency info is often pretty bad. I originally read "Available on non-crate feature blob only" as referring to a "non-crate feature" (whatever that would mean) named "blob". Anyways, that's an unrelated (and non-trivial) issue that should be addressed in a separate PR. @bors r+ rollup |
bors
added
S-waiting-on-bors
Rollup of 4 pull requests Successful merges: - #145883 (Make macOS dist build configuration match where reasonable) - #146457 (Skip cleanups on unsupported targets) - #147152 (builtin `Fn`-trait impls: instantiate binder before the return type `Sized` check) - #147153 ([rustdoc] Move doc cfg propagation pass before items stripping passes) r? `@ghost` `@rustbot` modify labels: rollup
|
I think this one implies that now intra-doc links are now checked in That is nice, since intra-doc links could be useful even if not rendered (e.g. for source view, IDEs, etc., plus to detect typos or if the docs get copied to public items, etc.), but I wanted to confirm whether that is expected behavior (because I need to clean up a couple cases in the kernel), and if so, whether we should add a test here on Thanks! |
| ConditionalPass::new(STRIP_HIDDEN, WhenNotDocumentHidden), | ||
| ConditionalPass::new(STRIP_PRIVATE, WhenNotDocumentPrivate), | ||
| ConditionalPass::new(STRIP_PRIV_IMPORTS, WhenDocumentPrivate), | ||
| ConditionalPass::always(COLLECT_INTRA_DOC_LINKS), |
There was a problem hiding this comment.
Revisiting thus due to ojeda's comment. Moving the intra-doc link pass before the strippers seems very much like a mistake.
I believe this PR was a response to my review comment #138907 (comment) in which I requested to move the doc cfg propagation pass before the strippers.
I haven't tried it out yet but that review comment wasn't properly addressed then.
(You did also change the ordering in PASSES but that's only used in the --help usage output IIRC)
There was a problem hiding this comment.
Did the added test also work before this PR?
… r=fmease rustdoc: Fix passes order so intra-doc links are collected after stripping passes Fixes regression I introduced in rust-lang#147153. This PR puts back the intra-doc link collecting pass after the stripping items pass, preventing lints to be emitted on non-visible items. Although, might be nice to add a way to change this behaviour. To be discussed later on. cc `@ojeda` r? `@fmease`
… r=fmease rustdoc: Fix passes order so intra-doc links are collected after stripping passes Fixes regression I introduced in rust-lang#147153. This PR puts back the intra-doc link collecting pass after the stripping items pass, preventing lints to be emitted on non-visible items. Although, might be nice to add a way to change this behaviour. To be discussed later on. cc `@ojeda` r? `@fmease`
… r=fmease rustdoc: Fix passes order so intra-doc links are collected after stripping passes Fixes regression I introduced in rust-lang#147153. This PR puts back the intra-doc link collecting pass after the stripping items pass, preventing lints to be emitted on non-visible items. Although, might be nice to add a way to change this behaviour. To be discussed later on. cc ``@ojeda`` r? ``@fmease``
Rollup merge of #147809 - GuillaumeGomez:fix-rustdoc-passes, r=fmease rustdoc: Fix passes order so intra-doc links are collected after stripping passes Fixes regression I introduced in #147153. This PR puts back the intra-doc link collecting pass after the stripping items pass, preventing lints to be emitted on non-visible items. Although, might be nice to add a way to change this behaviour. To be discussed later on. cc ``@ojeda`` r? ``@fmease``
7 participants
Follow-up of #138907.
r? lolbinarycat