-
Notifications
You must be signed in to change notification settings - Fork 747
doc: CodeReview.md: Clarify cfg usage #4012
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
@mwilbur as you added the I found the original PR with the justification here: #3208 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pending a slightly more careful read of the specific text I think this is right!
@@ -11,3 +11,7 @@ edition.workspace = true | |||
[dependencies] | |||
rv32i = { path = "../../arch/rv32i" } | |||
kernel = { path = "../../kernel" } | |||
|
|||
[lints.rust] | |||
# These are unused and unsupported |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# These are unused and unsupported | |
TODO: this is a non-canonical use of `cfg` predicates. This may represent dead code that should simply be removed, or a different mechanism for choosing its inclusion, such as a feature flag or generics, should be used. |
Rust `cfg` features can also be used to disable code that isn't used in upstream | ||
Tock but might be used in private or public forks. Rust custom configs can also | ||
be used, but generally require changes to the lint configuration. See | ||
https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html#check-cfg-in-lintsrust-table | ||
for more details on getting the Rust lints to pass. | ||
|
||
It would be better to use Cargo feature flags then `cfg`s and avoinding compile | ||
time configuration at all would be best. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's really not about upstream vs not upstream. There are many ways for code to exist in upstream that is used elsewhere without being disabled. It's about using conditional compilation at all, and the use of custom cfg
predicates in particular.
Rust `cfg` features can also be used to disable code that isn't used in upstream | |
Tock but might be used in private or public forks. Rust custom configs can also | |
be used, but generally require changes to the lint configuration. See | |
https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html#check-cfg-in-lintsrust-table | |
for more details on getting the Rust lints to pass. | |
It would be better to use Cargo feature flags then `cfg`s and avoinding compile | |
time configuration at all would be best. | |
Custom `cfg` predicates should never be used for conditional compilation unless unavoidable. It is virtually always better to Cargo feature flags, and even better to use non-conditional compilation mechanism (such as generics) to customize functionality at compile-time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to phrase it in a way that covers the aon_wkup_timer
cfg. It was included with "left for reference/use later", so it seemed like something we should allow in this wording
The new wording doesn't really allow that. Is that really what you want?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we want to expand this use case, and the text we have is what we want. Either the chip has functionality or it doesn't; hardware doesn't permit the ambiguity that motivates changes to this documentation (in my opinion).
Ok, #4013 merged, so I don't think we need this. Closing. |
Great! |
Pull Request Overview
As part of the latest Rust update, Clippy is now complaining when there are Rust
cfg
s or Cargo features that cannot be enabled.I want to remove the dead code, but @alevy has requested that we keep these configs as it is possible that the code is being used outside the repository (although the configs in questions can't be enabled without code changes and the functions are not public).
In order to update to the latest Rust nightly we need to expose the configs to keep the Rust lints happy. I don't want to sneak in a practice that clearly goes against the current Tock coding style. So I would like to update the docs to clarify Tock's position first.
I personally think this is a really bad idea. I don't think we should allow unused
cfg
s in mainline Tock. In this case the functions aren't public and the config isn't exposed, so code changes are required to use it anyway (although there appear to be no users).Testing Strategy
N/A
TODO or Help Wanted
N/A
Documentation Updated
/docs
, or no updates are required.Formatting
make prepush
.