[
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
|
Tomasz,
the parser certainly has to provide more information than what
is needed for indexing. Examples for that are
local variables, labels, details about
macro-expansions or #ifdef constructs. The problem bindings in
the AST
are motivated by the AST itself. They are created where
we fail to create a reasonable binding. (In particluar
note,
that detecting circular inheritance in the AST does not
prevent you from introducing cyclic inheritance
in the
index.)
The different kinds of problem bindings are not
well chosen. Many of them are reused too often,
a much better
description of why a problem binding had to be created
could be provided. Up to codan we did not
make use
of the different kinds, they simply did not
get enough attention.
It is unclear what you refer to by 'a correct PDOM' .
For example to find all references to user defined conversion functions
and constructors you would need to compute
all implicit conversions. Also, when using a non-static
member within a static member, is the resulting PDOM
correct? Most of the decisions have to be done
pragmatically. For me the main question is
not whether such a reference is correct, rather than that I ask myself:
"Is it useful to record
such a reference in the index?" And I think it is, because even if the reference
is wrong (a
compiler would never compile it) it is useful to be
able to navigate it.
My motivation to suggest extending the parser to let it
compute additional problems is that I believe that you
will
fail to implement these checks outside of the parser.
Some of them may also (optionally) be used by the
indexer
in order to find more of the implicit
references.
Markus.
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,
