贡献方式¶

Help is always appreciated!

To get started, you can try Building from Source in order to familiarizeyourself with the components of Solidity and the build process. Also, it may beuseful to become well-versed at writing smart-contracts in Solidity.

In particular, we need help in the following areas:

How to Report Issues¶

To report an issue, please use theGitHub issues tracker. Whenreporting issues, please mention the following details:

  • Which version of Solidity you are using
  • What was the source code (if applicable)
  • Which platform are you running on
  • How to reproduce the issue
  • What was the result of the issue
  • What the expected behaviour is
    Reducing the source code that caused the issue to a bare minimum is alwaysvery helpful and sometimes even clarifies a misunderstanding.

Workflow for Pull Requests¶

In order to contribute, please fork off of the develop branch and make yourchanges there. Your commit messages should detail why you made your changein addition to what you did (unless it is a tiny change).

If you need to pull in any changes from develop after making your fork (forexample, to resolve potential merge conflicts), please avoid using git mergeand instead, git rebase your branch.

Additionally, if you are writing a new feature, please ensure you write appropriateBoost test cases and place them under test/.

However, if you are making a larger change, please consult with the Solidity Development Gitter channel (different from the one mentioned above, this on isfocused on compiler and language development instead of language use) first.

Finally, please make sure you respect the coding standardsfor this project. Also, even though we do CI testing, please test your code andensure that it builds locally before submitting a pull request.

Thank you for your help!

Running the compiler tests¶

Solidity includes different types of tests. They are included in the applicationcalled soltest. Some of them require the cpp-ethereum client in testing mode,some others require libz3 to be installed.

To disable the z3 tests, use ./build/test/soltest — —no-smt andto run a subset of the tests that do not require cpp-ethereum, use ./build/test/soltest — —no-ipc.

For all other tests, you need to install cpp-ethereum and run it in testing mode: eth —test -d /tmp/testeth.

Then you run the actual tests: ./build/test/soltest — —ipcpath /tmp/testeth/geth.ipc.

To run a subset of tests, filters can be used:soltest -t TestSuite/TestName — —ipcpath /tmp/testeth/geth.ipc, where TestName can be a wildcard *.

Alternatively, there is a testing script at scripts/test.sh which executes all tests and runscpp-ethereum automatically if it is in the path (but does not download it).

Travis CI even runs some additional tests (including solc-js and testing third party Solidity frameworks) that require compiling the Emscripten target.

Whiskers¶

Whiskers is a templating system similar to Mustache. It is used by thecompiler in various places to aid readability, and thus maintainability and verifiability, of the code.

The syntax comes with a substantial difference to Mustache: the template markers {{ and }} arereplaced by < and > in order to aid parsing and avoid conflicts with Inline Assembly(The symbols < and > are invalid in inline assembly, while { and } are used to delimit blocks).Another limitation is that lists are only resolved one depth and they will not recurse. This may change in the future.

A rough specification is the following:

Any occurrence of <name> is replaced by the string-value of the supplied variable name without anyescaping and without iterated replacements. An area can be delimited by <#name>…</name>. It is replacedby as many concatenations of its contents as there were sets of variables supplied to the template system,each time replacing any <inner> items by their respective value. Top-level variables can also be usedinside such areas.

原文: http://solidity.apachecn.org/cn/doc/v0.4.21/contributing.html