I made using be a comment, but not namespace. In that case, it is
considered to be a type, and you could write a semantic patch to match
against it. Does that seem useful at all?
For now I mostly care about parsing to succeed, without actually being
able to use C++ features is semantic patches but still allowing simple C
spatches on C++ or mixed C/C++ codebase.
Hence I thought ignoring what would otherwise be a parsing error is a
good first step. The easiest way to ignore I found to be comments, but
adding simple placeholder tokens and touching files outside a lexer is
probably cleaner, even if the effect is still a noop.
I know of the following constructs (there may be others, I am not
experienced in C++) involving namespaces.
1) The using declaration:
using NS1::id;
using NS::ChildNS::id;
explicitly naming an identifier which may be part of an arbitrarily
nested namespace hierarchy.
This works without patches as 'using' is treated as a type name and the
rest as an identifier.
2) The using directive:
using namespace NS1;
'imports' namespace NS1 so one can refer to what is declared in it
without the NS1:prefix. (the example provided in the original mail)
3) Namespacing
something like
namespace NS1 {
int x;
int y;
}
namespace NS2 {
namespace NS3 {
int y;
}
}
This time the namespace keyword has another role. For simple parsing
only and not spatching purposes the namespace NS1 part could be treated
as comment and the block parsed as usual. This probably needs deeper
modification in the lexer as the program unit can now be divided in such
top level block declarations.
From what I saw in the lexer one can cheat and treat a sequence of
words separated by whitespace as tokens and make them a Tcomment,
so 'namespace space id' may match and be ignored. But that is not clean
at all :)
I think allowing a parse first without doing too many changes to
actually handle complex C++ constructs in semantic patch files would
already be helpful.
thanks
Jani
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
