Collaborate With Us

Every contribution is considered a donation and its copyright and any other related rights become exclusive ownership of the person who merged the code or in any other case the main developers of the "Cling Project". We warmly welcome external contributions to the Cling! By providing code, you agree to transfer your copyright on the code to the "Cling project". Of course you will be duly credited and your name will appear on the contributors page, the release notes, and in the CREDITS shipped with every binary and source distribution. The copyright transfer is necessary for us to be able to effectively defend the project in case of litigation.

You can send us a patch or a pull request with Github, provided that you follow these two simple rules:

• Make sure you follow the Cling coding conventions in your code.
• Make sure you provide a set of tests for your feature/bug fix.

Often it is useful to contact us first to discuss the code you want to develop or the bug you want to fix.

Picking up an Idea

We maintain a set of "ideas" for talented scientists and developers to pick up. An "idea" can be a sketch of a development project, a functionality, a missing feature we would like to see in our tool. A list that we propose is the following: Ideas

• Extending and improving the multiline input mode - The multiline mode has to figure out automatically whether the user's input is still incomplete. For example "if (a < 0) {" is not fully completed input. Cling should'n try to process the line but to be smart enough to understand that it should wait for continuation. Currently cling switches multiline mode only when there is trailing "{". It has to be extended to detect trailing +, unbalanced '," and so on.
• Implementing error recovery verifier - One of the most important parts in cling is the error recovery. The error recovery takes care of reverting clang's internal structures on error in the user input. For instance, user types int i; error_here;. int i should be reverted and the entire input should be invalidated. This is very complex because many implicit template instantiations could be triggered and so on. The idea of the future verifier is to serialize the AST with all the lookup structures (probably in pch or pcm), trigger an error causing a lot of things to happen in clang internally and serialize the new AST. The comparison with the old one must return perfect match.
• Enabling clang's static analyzer - coming soon
• Enabling ObjectiveC/ObjectiveC++ support - coming soon