[cdt-dev] Finding errors in code - in Parser or in Codan

[Tomasz Wesołowski <kosashi@xxxxxxxxx>]

Hello,

At the moment, the responsibility of finding errors in code relies on two separate components:
- Codan, which is a static analysis framework on its own and is able to generate problem markers and propose solutions,

- Parser, which generates problem bindings in the index on some errors in code (since bug 309760 is done, those are then found and reported in consistent way by one of the Codan checkers).

There's not really a big difference for the end-user on where do the presented errors originate, but I believe we should agree on some kind of policy "which component should report problem XYZ".

Let us have a look on what we have now:

a) Parser
All parser-generated problems are listed in org.eclipse.cdt.core.dom.ast.IProblemBinding. I'll cp them here for your convenience:

     * Attempt to use a symbol that was not found. 

    SEMANTIC_NAME_NOT_FOUND = 0x001;

     * Invalid overload of a particular name.

    SEMANTIC_INVALID_OVERLOAD = 0x002;

     * Invalid using directive.  

    SEMANTIC_INVALID_USING = 0x003;
    

     * Ambiguous lookup for given name. 
    SEMANTIC_AMBIGUOUS_LOOKUP = 0x004;

     * Invalid type provided
    SEMANTIC_INVALID_TYPE = 0x005;

     * circular inheritance was detected for a class
    SEMANTIC_CIRCULAR_INHERITANCE = 0x006;

     * the definition for the class/function can not be found
    SEMANTIC_DEFINITION_NOT_FOUND = 0x007;

    
     * the declaration for the K&R style function parameter can not be found

    SEMANTIC_KNR_PARAMETER_DECLARATION_NOT_FOUND = 0x008;
    

     * a label statement can not be found to match a goto statement
    SEMANTIC_LABEL_STATEMENT_NOT_FOUND = 0x009;

    
     * there was a problem creating the scope

    SEMANTIC_BAD_SCOPE = 0x00A;
    

     * invalid redefinition of the name
    SEMANTIC_INVALID_REDEFINITION = 0x00B;

    
     * invalid re-declaration of the name

    SEMANTIC_INVALID_REDECLARATION = 0x00C;
    

    SEMANTIC_MEMBER_DECLARATION_NOT_FOUND = 0x00D;
    

    SEMANTIC_RECURSION_IN_LOOKUP = 0x00E;

    SEMANTIC_INVALID_TEMPLATE_ARGUMENTS = 0x00F;

Most of those is detected and forwarded to the user by Codan. (I also believe that not all of them are functional, i.e. SEMANTIC_CIRCULAR_INHERITANCE.)

(Note that Codan's still responsible for providing user-friendly names to those problems, as well as severity preferences and quick fixes for those - I believe it's OK.)

b) Codan

The Problems generated by Codan are listed in /org.eclipse.cdt.codan.checkers/plugin.xml , as "problem" subnodes of "checker" nodes in org.eclipse.cdt.codan.core.checkers extension.

Excluding those forwarded from Parser, Codan finds on its own and reports the following problems:

Assignment in condition


Statement has no effect

Non-virtual destructor


Catch-by-reference recommended

Suggested parenthesis around _expression_

Name convention for function

Return value inconsistencies

Assignment to itself

---

As the list of detected problems is going to grow, we should decide: Which problems shall be found by Parser, and which by Codan checkers? I believe we need a consistent rule here.

---

Note that all Parser problems are actually problems which will break the compilation.
As for Codan, most of those (except return value inconsistencies) are either  or potential sources of bugs or coding convention or good style issues. 

Does this sound like a good rule to you?


Best regards,

-- Tomasz Wesołowski