Omit version constraints if the surrounding scope already guards these #1080
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@GuillaumeGomez Thanks! Upon re-reading the PR description, do note that those screenshots do not show the current situation! This PR only cleans up the code but the main issue is either solved by applying the temporary workaround mentioned in #1079 or automagically when it is addressed in rustdoc: rust-lang/rust#83428. Apologies for selling "misleading" pretty pictures 😅 |
MarijnS95
force-pushed
the
deduplicate-cfg-guards
branch
from
3840eae to
6b08412
Compare
This removes unnecessary (duplicate) `#[cfg]` attributes on `fn`s where the surrounding `impl` block (in `enums`/`flags`) or `mod` (when in a file that fully defines a `struct`) already declares this constraint. When the feature requirement is already described it is superfluous (and noisy) to specify it again. Besides, rustdoc omits duplicate feature requirements if it can show this just once at the top of the page for the entire `struct`.
This removes unnecessary (duplicate) `#[cfg]` attributes on trait implementations where the surrounding `mod` (when in a file that fully defines a `struct`) already declares this constraint. This does not suffice for `flags`/`enums` where multiple types live in a single shared file without surrounding constraint. When the feature requirement is already described it is superfluous (and noisy) to specify it again. Besides, rustdoc omits duplicate feature requirements if it can show this just once at the top of the page for the entire `struct`.
This removes unnecessary (duplicate) `#[cfg]` attributes on `use` imports where the surrounding `mod` (when in a file that fully defines a `struct`) already declares this constraint. This does not suffice for `flags`/`enums` where multiple types live in a single shared file without surrounding constraint. When the feature requirement is already described it is superfluous (and noisy) to specify it again.
MarijnS95
force-pushed
the
deduplicate-cfg-guards
branch
from
6b08412 to
71e84df
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Originally committed and discussed in #991 (comment) / #991 (comment), these patches can finally be submitted as
rustdocautomatically propagates feature requirements on modules to the items within it, showing it conveniently on the top of the page without a singledoc(cfg())residing inside this file anymore:Note that rustdoc automatically coalesces to this already! This PR just cleans up the code so that it's easier to read through: a loose
#[cfg]statement makes it seem like something special is going on, even though it is simply repeating what is already declared on themodas a whole. See: https://github.com/MarijnS95/gtk-rs/compare/deduplicate-cfg-guardsUnfortunately a bug with publicly reexporting private modules (ie. our
mod auto; pub use crate::auto::*;) preventsrustdocfrom figuring out this type constraint onstructs, and instead opts to propagate the requirement to each and every member :( (#1079):That is already the case on
master(see it for yourself!) and this PR does nothing to alleviate the situation.