Table of Contents
How to Contribute
We want to make contributing to CompilerGym as easy and transparent as possible. The most helpful ways to contribute are:
Report bugs. In particular, it’s important to report any crash or correctness bug. We use GitHub issues to track public bugs. Please ensure your description is clear and has sufficient instructions to be able to reproduce the issue.
Report issues when the documentation is incomplete or unclear, or an error message could be improved.
Make feature requests. Let us know if you have a use case that is not well supported, including as much detail as possible.
Contribute to the CompilerGym ecosystem.
We actively welcome your pull requests.
Fork the repo and create your branch from
Follow the instructions for building from source to set up your environment.
If you’ve added code that should be tested, add tests.
If you’ve changed APIs, update the documentation.
make testsuite passes.
Make sure your code lints (see Code Style below).
If you haven’t already, complete the Contributor License Agreement (“CLA”).
To add a new result to the leaderboard, add a new entry to the leaderboard table and file a Pull Request. Please include:
A list of all authors.
A CSV file of your results. The compiler_gym.leaderboard package provides utilities to help generate results using your agent.
A write-up of your approach. You may use the submission template (leaderboard/SUBMISSION_TEMPLATE.md) as a guide.
Please make sure to update to the latest CompilerGym release prior to submission. We do not require that you submit the source code for your approach, though we encourage that you make it publicly available. Once you submit your pull request we will validate your results CSV files and may ask clarifying questions if we feel that those would be useful to improve reproducibility. Take a look here for an example of a well-formed pull request submission.
We want to ease the burden of code formatting using tools. Our code style is simple:
C++: Google C++ style with 100 character line length and
Other common sense rules we encourage are:
Prefer descriptive names over short ones.
Split complex code into small units.
When writing new features, add tests.
Make tests deterministic.
Prefer easy-to-use code over easy-to-read, and easy-to-read code over easy-to-write.