Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Check macro usage on every identifier like token: issues and discussions
ollydbg:
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
--- Code: ---#define type(obj) ((obj)._type)
--- End code ---
or even bad
--- Code: ---#define type xxx
--- End code ---
And we have some other target which can have some code like:
--- Code: --- GdbCmd_SetCatch(DebuggerDriver *driver, const wxString &type, int *resultIndex)
--- End code ---
In this case, the "type" was replaced to un-wanted tokens.
2, we have some code like:
--- Code: ---// 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
{
public:
// Default ctor, must subsequently call Init for two stage construction.
wxBufferedDC()
: m_dc(NULL),
m_buffer(NULL),
m_style(0)
{
}
// Construct a wxBufferedDC using a user supplied buffer.
wxBufferedDC(wxDC *dc,
wxBitmap& buffer = wxNullBitmap,
int style = wxBUFFER_CLIENT_AREA)
: m_dc(NULL), m_buffer(NULL)
{
Init(dc, buffer, style);
}
--- End code ---
When parsing the function arguments(parameters), if macro expansion is enabled on every tokens, we will get
--- Code: ---(wxDC *dc, wxBitmap& buffer = wxNullBitmap, int style = 0x02)
--- End code ---
instead of
--- Code: ---(wxDC *dc, wxBitmap& buffer = wxNullBitmap, int style = wxBUFFER_CLIENT_ARE)
--- End code ---
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)
EDIT: 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
Huki:
--- Quote from: ollydbg on April 06, 2015, 02:51:59 am ---Hi, Huki, I attach the git patch serials against the latest trunk rev 10182.
Comments are welcome :)
--- End quote ---
I've attached some bug fix patches against your last cc_macro serials. Some description:
Fixed = [] , handling when parsing variable declaration. i.e.,
--- Code: (assignment parsing) ---int var1 = 0; // this var has an assignment
int var2 = 0; // mouse on var2 -> we get "intint var2"
int var3 = 0; // mouse on var3 -> we get "intintint var3"
--- End code ---
--- Code: (comma parsing) ---int num=0, num2=0, num3=0;
// mouse on each variable and we get:
// num -> "int num"
// num2 -> "int, num2"
// num3 -> "int,, num3"
--- End code ---
--- Code: (arrays parsing) ---int array[5]; // vars with [] are not parsed
--- End code ---
The rest of the patches should already be clear.
ollydbg:
--- Quote from: Huki on April 09, 2015, 07:11:18 pm ---
--- Quote from: ollydbg on April 06, 2015, 02:51:59 am ---Hi, Huki, I attach the git patch serials against the latest trunk rev 10182.
Comments are welcome :)
--- End quote ---
I've attached some bug fix patches against your last cc_macro serials. Some description:
...
--- End quote ---
Very nice work, Huki, thanks. I have them applied in my local copy, it fixes some errors of my patch serials.
BTW: I see a trailing spaces in a patch when I run the "git am" command
--- Code: ---Applying: CC: fix variable parsing with "=" or "[]"
f:/cb_sf_git/trunk/.git/rebase-apply/patch:52: trailing whitespace.
|| peek==ParserConsts::oparray_chr
warning: 1 line adds whitespace errors.
--- End code ---
Do you have the "remove trailing space" option enabled in C::B?
Any suggestion is that the commit message should have a "*" if it is a major function change or "-" if it is a minor change.
So, it should be:
--- Code: ---* CC: xxxxxxx
detailed descriptions
--- End code ---
You can wrote as many detailed text as possible in the commit log messages, E.g. see my commit r10157 as an example. I just follow Linux's commit message style, which means a simple line as a subject, and after an empty line, write details, like this: Git Commit Messages : 50/72 Formatting.
EDIT: I have fixed all the mentioned issue above in my local copy, so you don't need to post the patches again. :)
MortenMacFly:
Well guys it would be nice to follow but the patches don't apply in svn. Any chance you make svn compatible patches or a svn branch or work together on a git repo? The repo that I was referring to is terribly old... Or am I missing something?
ollydbg:
--- Quote from: MortenMacFly on April 11, 2015, 10:13:48 pm ---Well guys it would be nice to follow but the patches don't apply in svn. Any chance you make svn compatible patches or a svn branch or work together on a git repo? The repo that I was referring to is terribly old... Or am I missing something?
--- End quote ---
Hi, Morten, I attach the svn style patch which is created from this script.
Navigation
[0] Message Index
[#] Next page
Go to full version