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

[Tomasz Wesołowski <kosashi@xxxxxxxxx>]

Hello,

A suggestion about making the parser's performance the priority makes sense. However the parser indeed has been doing some semantic checks for some time and I believe there's a reason for that.


Having considered this matter for some time, my idea for a rule of division of responsibility between Parser and Codan would be:

The parser shall create problem bindings for those errors which prevent it from building correct (consistent) PDOM.

This reasoning would be quite consistent with what's being reported right now. Some examples for clarity:
- use of undefined symbol: this is a parser problem because then it's impossible to answer resolveBinding() on a given ASTName

- incompatible types in assignment: this is not a parser problem because both AST can be created and no index queries are affected.

Thus, the former looks like a problem which shall have an IProblemBinding generated and the latter doesn't.


Let's have a look on what's there at the moment:
    SEMANTIC_NAME_NOT_FOUND = 0x001;

    SEMANTIC_INVALID_OVERLOAD = 0x002;
Clearly OK, as it prevents a valid resolveBinding()


     * Invalid using directive.  
    SEMANTIC_INVALID_USING = 0x003;
The same, I think. 

    SEMANTIC_AMBIGUOUS_LOOKUP = 0x004;


    SEMANTIC_INVALID_TYPE = 0x005;
Again.

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

This is a bit disputable.
On one hand, for every class, a binding can be resolved with no problem.

On the other hand, a client (say, a code metrics plug-in) could expect that the PDOM would contain only consistent information - so also a correct inheritance graph, on which it could run a DF-search safely, on the assumption that it doesn't contain cycles.

However, an IProblemBinding would basically mean "beware, you can look up this class in index, but the part of PDOM which you receive will be in inconsistent state because the parser has found a cycle in inheritance graph". 

(BTW- I'm not quite sure this is working at the moment?)

    SEMANTIC_DEFINITION_NOT_FOUND = 0x007;


    SEMANTIC_KNR_PARAMETER_DECLARATION_NOT_FOUND = 0x008;
    SEMANTIC_LABEL_STATEMENT_NOT_FOUND = 0x009;

Again, cannot resolve binding

    SEMANTIC_BAD_SCOPE = 0x00A;

    SEMANTIC_INVALID_TEMPLATE_ARGUMENTS = 0x00F;

I'm not really sure how those work.

    SEMANTIC_INVALID_REDEFINITION = 0x00B;


    SEMANTIC_INVALID_REDECLARATION = 0x00C;    
    SEMANTIC_MEMBER_DECLARATION_NOT_FOUND = 0x00D;
    SEMANTIC_RECURSION_IN_LOOKUP = 0x00E;
The same - all prevent from resolving the binding correctly, by introducing ambiguities or otherwise.


About Markus' suggestions:

* [c++] Use of non-static member function or field without an object pointer.

* [c++] Use of inaccessible members.

* [c/c++] Problems in implicit convertions for assignments, return statements and (in c++) throw expressions.

* [c] Implicit conversions for arguments of function-calls where the function has a prototype.

Note that those are related to expressions, which are not a part of PDOM (except for listing references), so the parser doesn't really need to care about those problems - they don't affect its task of creating a correct index.

Because of that reason (not being strictly index-related), I believe that they are perfect candidates for Codan checkers.


Best regards,

-- Tomasz Wesołowski