[
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
|
Yes it is good to operate the parser in a least effort mode
for indexing. On the other hand it is reasonable to
use the parser to detect a class of problems that would
otherwise be hard to identify. Therefore I suggest to create a mechanism in the
parser that allows to compute more problems for an AST in a second parsing
step (see bug 263154).
My top candidates for that are:
* [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.
Markus.
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,
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev