We have already enabling some kind of macro usage check in our parser(see rev9932), but that's not fully.
My idea was try to enable the macro checking on each identifier like tokens, I did some tests, and it won't slow down much of the parsing speed, the result is quite good.
But we still have some issues to solve
1, we have different build target, and different build target have different C Preprocessor definitions, if we still parse the whole C::B project, we can get bad result.
E.g. In Codeblocks.cbp, we have one macro definition in one target
#define type(obj) ((obj)._type)
or even bad
#define type xxx
And we have some other target which can have some code like:
GdbCmd_SetCatch(DebuggerDriver *driver, const wxString &type, int *resultIndex)
In this case, the "type" was replaced to un-wanted tokens.
2, we have some code like:
// Assumes the buffer bitmap only covers the client area;
// does not prepare the window DC
#define wxBUFFER_CLIENT_AREA 0x02
class WXDLLEXPORT wxBufferedDC : public wxMemoryDC
// Default ctor, must subsequently call Init for two stage construction.
// Construct a wxBufferedDC using a user supplied buffer.
wxBitmap& buffer = wxNullBitmap,
int style = wxBUFFER_CLIENT_AREA)
: m_dc(NULL), m_buffer(NULL)
Init(dc, buffer, style);
When parsing the function arguments(parameters), if macro expansion is enabled on every tokens, we will get
(wxDC *dc, wxBitmap& buffer = wxNullBitmap, int style = 0x02)
(wxDC *dc, wxBitmap& buffer = wxNullBitmap, int style = wxBUFFER_CLIENT_ARE)
What would you like to see? The former or the later?
3, In the further, I would like to see that all the macro handling was put in the Tokenizer class. (Currently, we have macro handling both in Parserthread and Tokenizer class).
4, Too speed up the macro definition search, I think a hash table (e.g. wxWidgets: wxHashMap Class Reference
) is preferred. (Currently, the macro definition is stored in the TokenTree, which is actually a Trie - Wikipedia, the free encyclopedia
Even in the same build target, we can still have different C preprocessor definitions for different translation file, so this seems not easy to solve. One method is that we try to maintain macro definition for each file, or create a include file hierarchy.EDIT2:
Patches (git patches serial) attached, comments were welcome.EDIT3:
About issue 1, I think we have discussed here, see Huki's comments Re: Several improvements to Code Completion plugin
and Re: Several improvements to Code Completion plugin