Fix doc_cfg not working as expected on trait impls#153964
Fix doc_cfg not working as expected on trait impls#153964rust-bors[bot] merged 5 commits intorust-lang:mainfrom
doc_cfg not working as expected on trait impls#153964Conversation
This comment has been minimized.
This comment has been minimized.
doc_cfg not working as expected on trait impls
This comment has been minimized.
This comment has been minimized.
|
Not great that |
|
And CI passed. \o/ |
src/librustdoc/clean/mod.rs
Outdated
| impl_: &hir::Impl<'tcx>, | ||
| def_id: LocalDefId, | ||
| cx: &mut DocContext<'tcx>, | ||
| // If `renamed` is some, then this is an inlined impl and it will be handled later on in the |
There was a problem hiding this comment.
nit: ambiguous pronoun, this would be less ambiguous if "this" was replaced with an actual name.
src/librustdoc/passes/stripper.rs
Outdated
|
|
||
| clean::ImplItem(..) => {} | ||
|
|
||
| // They have no use anymore, so always remove them. |
There was a problem hiding this comment.
nit: great comments explain why code does something.
| @@ -0,0 +1,59 @@ | |||
| // This test ensures that `doc_cfg` feature is working as expected on trait impls. | |||
There was a problem hiding this comment.
just to be sure: we do have a test for non-trait impls, right? we definitely don't want to regress that.
also, do we have a test for non-auto doc(cfg(...)) on trait items?
There was a problem hiding this comment.
Doesn't hurt to add one in the same test I guess. Gonna add a test for non-auto doc(cfg(...)) too.
ce71ac8 to
2dd7677
Compare
This comment has been minimized.
This comment has been minimized.
|
Added comments and greatly extended the tests. |
This comment has been minimized.
This comment has been minimized.
|
Seems like a flaky failure. Restarted CI. |
There was a problem hiding this comment.
I took a closer look at the actual logic this time and it seems solid and straightforwards, I can't come up with any edge cases that it would cause problems in.
My only issue of immediate relevance is rustc_span::symbol::kw::Impl and renamed being used in a somewhat unintuitive way, not sure what the best way to address that is but it definitely has an impact on code readability. I also found some missing test coverage but that's mostly unrelated so that can be handled in a followup PR if you want.
2dd7677 to
3f0f7d7
Compare
|
I added code comments to explain that the symbol is used as a sentinel value. |
src/librustdoc/visit_ast.rs
Outdated
| if impl_.of_trait.is_none() { | ||
| None | ||
| } else { | ||
| Some(rustc_span::symbol::kw::Impl) | ||
| }, |
There was a problem hiding this comment.
Would replacing parameter type Option<Symbol> with Option<BikeshedTy> be possible / much of a hassle where BikeshedTy is a new type that could be defined like enum BikeshedTy { BikeshedName(Symbol), BikeshedAnon }? I haven't read the rest of the diff, lol
There was a problem hiding this comment.
Context: this argument is what an inlined item is renamed into. So no, I don't want to rename it. 😝
…amples-improvement, r=lolbinarycat Don't emit rustdoc `missing_doc_code_examples` lint on impl items @lolbinarycat realized in [this comment](rust-lang#153964 (comment)) that we weren't testing some cases for the `missing_doc_code_examples` lint. Turns out that it was not handling this case well. =D So in short: `missing_doc_code_examples` lint should not be emitted on impl items and this PR fixes that. r? @lolbinarycat
…amples-improvement, r=lolbinarycat Don't emit rustdoc `missing_doc_code_examples` lint on impl items @lolbinarycat realized in [this comment](rust-lang#153964 (comment)) that we weren't testing some cases for the `missing_doc_code_examples` lint. Turns out that it was not handling this case well. =D So in short: `missing_doc_code_examples` lint should not be emitted on impl items and this PR fixes that. r? @lolbinarycat
…amples-improvement, r=lolbinarycat Don't emit rustdoc `missing_doc_code_examples` lint on impl items @lolbinarycat realized in [this comment](rust-lang#153964 (comment)) that we weren't testing some cases for the `missing_doc_code_examples` lint. Turns out that it was not handling this case well. =D So in short: `missing_doc_code_examples` lint should not be emitted on impl items and this PR fixes that. r? @lolbinarycat
This comment has been minimized.
This comment has been minimized.
3f0f7d7 to
2752dc5
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Fixed merge conflict. |
src/librustdoc/clean/mod.rs
Outdated
| // If `renamed` is some, then `impl_` is an inlined impl and it will be handled later on in the | ||
| // code. In here, we will generate a placeholder for it in order to be able to compute its | ||
| // `doc_cfg` info. | ||
| renamed: Option<Symbol>, |
There was a problem hiding this comment.
After some reflection I think this should probably just be a boolean parameter called something like is_inlined. I feel like too often rustdoc just passes variables along as function parameters with the same name, even when they don't really make sense in that context. Although why are we saying "inlined" and not "trait" here? Is there some subtle difference I'm missing?
If this item is renamed, we can probably remove the comment, but we'll definitely need to make sure that the comment in clean_maybe_renamed_item is updated to still make sense.
| cx: &'a mut DocContext<'tcx>, | ||
| cfg_info: CfgInfo, | ||
|
|
||
| /// To ensure the `doc_cfg` feature works with how `rustdoc` handles impl, we need to store |
There was a problem hiding this comment.
| /// To ensure the `doc_cfg` feature works with how `rustdoc` handles impl, we need to store | |
| /// To ensure the `doc_cfg` feature works with how `rustdoc` handles impls, we need to store |
nit: typo
| // If we have an impl, we check if it has an associated `cfg` "context", and if so we will | ||
| // use this context instead of the actual (wrong) one. |
There was a problem hiding this comment.
| // If we have an impl, we check if it has an associated `cfg` "context", and if so we will | |
| // use this context instead of the actual (wrong) one. | |
| // If we have an impl, we check if it has an associated `cfg` "context", and if so we will | |
| // use that context instead of the actual (wrong) one. |
very minor and somewhat subjective nit
| // them up regardless of where they're located. | ||
| if !self.inlining && impl_.of_trait.is_none() { | ||
| self.add_to_current_mod(item, None, None); | ||
| if !self.inlining { |
There was a problem hiding this comment.
Instead of copy-pasting this code, I'd like to see it refactored into a utility method add_impl_to_current_mod.
2752dc5 to
19876d1
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
|
Applied all suggestions! |
|
Thanks! @bors r+ |
…cfg, r=lolbinarycat Fix `doc_cfg` not working as expected on trait impls Fixes rust-lang#153655. I spent waaaaay too much time on this fix. So the current issue is that rustdoc gets its items in two passes: 1. All items 2. Trait/blanket/auto impls Because of that, the trait impls are not stored "correctly" in the rustdoc AST, meaning that the `propagate_doc_cfg` pass doesn't work correctly on them. So initially, I tried to "clean" the impls at the same time as the other items. However, it created a monstruous amount of bugs and issues and after two days, I decided to give up on this approach (might be worth fixing that in the future!). You can see what I tried [here](https://github.com/rust-lang/rust/compare/main...GuillaumeGomez:trait-impls-doc_cfg?expand=1). So instead, since the impls are stored at the end, I create placeholders for impls and in `propagate_doc_cfg`, I store the `cfg` "context" (more clear when reading the code 😛) and re-use it later on when the "real" impl comes up. r? @lolbinarycat
Rollup of 10 pull requests Successful merges: - #153964 (Fix `doc_cfg` not working as expected on trait impls) - #153979 (Rename various query cycle things.) - #154132 (Add missing num_internals feature gate to coretests/benches) - #154153 (core: Implement `unchecked_funnel_{shl,shr}`) - #154236 (Clean up query-forcing functions) - #154252 (Don't store current-session side effects in `OnDiskCache`) - #154017 ( Fix invalid add of duplicated call locations for the rustdoc scraped examples feature) - #154163 (enzyme submodule update) - #154264 (Update books) - #154282 (rustc-dev-guide subtree update)
…, r=eggyal,tgross35 [libcore] Disable `doc(auto_cfg)` for integers trait impls Fixes rust-lang#153655. Thanks to rust-lang#153964, `doc(auto_cfg)` finally works as expected on impls. So now this fix works: <img width="1000" height="806" alt="image" src="https://github.com/user-attachments/assets/f37da375-c2eb-4a7b-abf2-1fdd3a73e2bb" /> cc @eggyal
…, r=eggyal,tgross35 [libcore] Disable `doc(auto_cfg)` for integers trait impls Fixes rust-lang#153655. Thanks to rust-lang#153964, `doc(auto_cfg)` finally works as expected on impls. So now this fix works: <img width="1000" height="806" alt="image" src="https://github.com/user-attachments/assets/f37da375-c2eb-4a7b-abf2-1fdd3a73e2bb" /> cc @eggyal
Fixes #153655.
I spent waaaaay too much time on this fix. So the current issue is that rustdoc gets its items in two passes:
Because of that, the trait impls are not stored "correctly" in the rustdoc AST, meaning that the
propagate_doc_cfgpass doesn't work correctly on them. So initially, I tried to "clean" the impls at the same time as the other items. However, it created a monstruous amount of bugs and issues and after two days, I decided to give up on this approach (might be worth fixing that in the future!). You can see what I tried here.So instead, since the impls are stored at the end, I create placeholders for impls and in
propagate_doc_cfg, I store thecfg"context" (more clear when reading the code 😛) and re-use it later on when the "real" impl comes up.r? @lolbinarycat