8000 doc: CodeReview.md: Clarify cfg usage by alistair23 · Pull Request #4012 · tock/tock · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

Closed
wants to merge 1 commit into from

Conversation

alistair23
Copy link
Contributor

Pull Request Overview

As part of the latest Rust update, Clippy is now complaining when there are Rust cfgs 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 cfgs 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

  • Updated the relevant files in /docs, or no updates are required.

Formatting

  • Ran make prepush.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
@github-actions github-actions bot added the WG-OpenTitan In the purview of the OpenTitan working group. label Jun 3, 2024
@alistair23
Copy link
Contributor Author

@mwilbur as you added the #[cfg(aon_wkup_timer)]

I found the original PR with the justification here: #3208 (comment)

Copy link
Member
@alevy alevy left a 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# 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.

Comment on lines +347 to +354
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.
Copy link
Member

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.

Suggested change
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.

Copy link
Contributor Author

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?

Copy link
Contributor
@bradjc bradjc left a 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).

8000
@alevy
Copy link
Member
alevy commented Jun 4, 2024

Ok, #4013 merged, so I don't think we need this. Closing.

@alevy alevy closed this Jun 4, 2024
@alistair23
Copy link
Contributor Author

Great!

@alistair23 alistair23 deleted the alistair/doc-update branch June 4, 2024 21:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
WG-OpenTitan In the purview of the OpenTitan working group.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0