8000 tock-cells: make TakeCell constructor a const fn by lschuermann · Pull Request #2214 · tock/tock · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

tock-cells: make TakeCell constructor a const fn #2214

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

lschuermann
Copy link
Member
@lschuermann lschuermann commented Nov 22, 2020

Pull Request Overview

This pull request changes the TakeCell to be a const fn, such that it can be used in other const fns (as used in PR #2203, port to LiteX SoCs).

This requires the const_mut_refs feature, which is already enabled in the tock-cells crate.

Testing Strategy

This pull request was tested by compiling.

TODO or Help Wanted

N/A

Documentation Updated

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

Formatting

  • Ran make prepush.

@lschuermann lschuermann mentioned this pull request Nov 22, 2020
12 tasks
@hudson-ayers
Copy link
Contributor

Can you give a pointer to where in #2203 requires this change? I would have thought that with the peripheral instantiation changes moving away from the use of global variables there should not be much need for const cell constructors (in fact, part of the original motivation for those changes was to allow us to reduce our reliance on various portions of the const_fn unstable feature).

@lschuermann
Copy link
Member Author

@hudson-ayers You're right! The LiteEth driver constructor used to be required const due to the way I've done peripheral instantiation prior to integrating your solution. As you've actually noted in rust-lang/rust#57349 we're not going to get around using const_mut_refs in tock-cells, so what this adds will probably stabilize at the same time as the other uses. Would this still be worth adding then? Or should we refrain from adding this?

@hudson-ayers
Copy link
Contributor
9B87 hudson-ayers commented Nov 23, 2020

I would prefer not to add it if there is not a use case that requires it. Somewhere in my work backlog is a plan to remove const constructors from OptionalCell and MapCell as part of reducing our reliance on the various sub-parts of const_fn.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0