Skip to content
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

Increase use of C constexpr constant expressions in the code base. #7720

Closed
ekpyron opened this issue Nov 14, 2019 · 4 comments
Closed

Increase use of C constexpr constant expressions in the code base. #7720

ekpyron opened this issue Nov 14, 2019 · 4 comments
Labels
closed due inactivity The issue/PR was automatically closed due to inactivity. good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. medium difficulty stale The issue/PR was marked as stale because it has been open for too long.

Comments

@ekpyron
Copy link
Member

ekpyron commented Nov 14, 2019

Came up in #7655 (comment) with one minor example for this.
But in general I'd expect a lot of places in the compiler could be refactored to benefit from constant expressions. One prominent example would be the simplification rule list, which is entirely compile time constant and with a bit of care could be constexpr initialized to a std::array which could live statically in the data segment. That might especially have beneficial consequences for the emscripten builds and the stack issues.
There's probably a lot of other places as well.

@chriseth
Copy link
Contributor

This requires rather modern compilers, though.

@ekpyron
Copy link
Member Author

ekpyron commented Nov 18, 2019

For a lot of stuff like this compilers that are actually C 17 standard compliant should be sufficient... but yeah - for more complex stuff like the rule list this would be rather tricky and would probably also require quite some restructuring, so that we'd have to evaluate separately.

@christianparpart
Copy link
Member

I think one may want to start with the obvious stuff, and create smaller PRs for each iteration (whenever they come up), and by the time, evaluate whether or not it makes sense to also migrate the more complex stuff.

However, I'd highly recommend to apply constexpr as much as possible, since it's also ensuring we have no undefined behavior.

benldrmn added a commit to benldrmn/solidity that referenced this issue Aug 14, 2021
hrkrshnn pushed a commit to benldrmn/solidity that referenced this issue Aug 26, 2021
Marenz pushed a commit to benldrmn/solidity that referenced this issue Aug 31, 2021
@NunoFilipeSantos NunoFilipeSantos added the stale The issue/PR was marked as stale because it has been open for too long. label Nov 25, 2022
@cameel cameel added good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. and removed good first issue labels Dec 5, 2022
@github-actions
Copy link

github-actions bot commented Feb 3, 2023

Hi everyone! This issue has been closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.

@github-actions github-actions bot added the closed due inactivity The issue/PR was automatically closed due to inactivity. label Feb 3, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Feb 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed due inactivity The issue/PR was automatically closed due to inactivity. good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. medium difficulty stale The issue/PR was marked as stale because it has been open for too long.
Projects
None yet
Development

No branches or pull requests

5 participants