[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Finding errors in code - in Parser or in Codan
|
I agree. Parser/Indexer would only find minimum number of error -
parsing or binding errors, others should be find by codan, that is its
purpose.
On Fri, Sep 10, 2010 at 1:23 PM, Sergey Prigogin
<eclipse.sprigogin@xxxxxxxxx> wrote:
> Parser doesn't detect several types of errors that would break compilation.
> One example is type incompatibility in assignment statements. We should not
> try to force parser to find more errors, since it would cost parsing speed.
> It should be a responsibility of Codan to find all errors, breaking
> compilation or not, that parser does not uncover.
> -sergey
>
> On Fri, Sep 10, 2010 at 10:10 AM, Tomasz Wesołowski <kosashi@xxxxxxxxx>
> wrote:
>>
>> 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
>>
>>
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
