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

Consider preprocessor on solidity code #143

Open
dtebbs opened this issue Dec 19, 2019 · 1 comment
Open

Consider preprocessor on solidity code #143

dtebbs opened this issue Dec 19, 2019 · 1 comment
Labels
optimization Optimization task solidity Task related to the Solidity part of the code base

Comments

@dtebbs
Copy link
Contributor

dtebbs commented Dec 19, 2019

Significant optimizations are possible if certain configuration values are known at compile time (in particular, depth of the merkle tree, number of inputs / outputs, which allow much more efficient data structures in memory and storage).

Consider ways to share the configuration information with src/zeth.h and use this as constants in solidity code.

@AntoineRondelet AntoineRondelet added optimization Optimization task solidity Task related to the Solidity part of the code base labels Dec 19, 2019
@dtebbs
Copy link
Contributor Author

dtebbs commented Jan 22, 2020

Since there is no preprocessor in solc, it seems there is no nice way of handling this. IDE's will likely break completely and the compile will not show the correct location of errors and warings, which is a pretty big impact on workflow.

I see three main options:

  1. Change the compile process to use solpp and/or gcc to combine all the files, include zeth.h and substitue macros, before passing everything to the solc compiler. This will break all IDEs and error and warning message will all refer to stdin instead of file names, which will be very opaque.

  2. Change the compile process to run solpp and gcc on each file, write those files into another directory, and then run solc on files in that dir. This will still break all IDEs. Error and warning messages will refer to the wrong directories, but file and line numbers should at least be accurate. There is a danger that people will edit these "generated" files, but we could mitigate that by deleteing them after the compile step.

  3. Create a wrapper around solc that writes all pre-processed files into a directory, performs the compile on those files, and then rewrites the error / warning messages and the output json, to refer to the original files. This should generate useful errors and warnings, and IDE's could be configured to use this wrapper tool instead of solc. But it's a rather heavy-weight solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
optimization Optimization task solidity Task related to the Solidity part of the code base
Projects
None yet
Development

No branches or pull requests

2 participants