Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Several improvements to Code Completion plugin
dekar:
Is there some technique to make Code Completion interpret defines?
for example:
--- Code: ---((Some_struct*) someAddr)->
--- End code ---
completing correctly. But
--- Code: ---#define AVAR ((Some_struct*) someAddr)
AVAR->
--- End code ---
does not wokr.
It is rely annoying with embedded programming.
ollydbg:
--- Quote from: ollydbg on January 04, 2014, 10:38:49 am ---Today, I have tested the patch: cc_includes_parsing.patch
But I found it cause some GUI hang problem, see my report question about running parser in thread, I guess the reason is:
If you recursively parse the #include directive.
--- Code: --- if (!locked)
CC_LOCKER_TRACK_TT_MTX_LOCK(s_TokenTreeMutex)
//this is a recursive call to Parse() function????
result = thread->Parse();
delete thread;
if (!locked)
CC_LOCKER_TRACK_TT_MTX_UNLOCK(s_TokenTreeMutex)
--- End code ---
So, you hold the s_TokenTreeMutex for a very long time. Some GUI function may try to query information from Tokentree, thus they get hangs.
--- End quote ---
I have a improvement patch to handle this (see attachment). The parser only parses cpp files in the project, recursive call the parse function when it meet the #include directive, the result is quite good.
The only issue about this is that if the project contains some header files(like a header only library project) which does not used by any cpp file, they will be left. I don't think this is a very big issue, because a user project will include those headers, then it still get parsed correctly.
ollydbg:
--- Quote from: dekar on January 20, 2014, 01:18:14 pm ---Is there some technique to make Code Completion interpret defines?
for example:
--- Code: ---((Some_struct*) someAddr)->
--- End code ---
completing correctly. But
--- Code: ---#define AVAR ((Some_struct*) someAddr)
AVAR->
--- End code ---
does not wokr.
It is rely annoying with embedded programming.
--- End quote ---
I think currently it is not, so it should be a feature request.
We need to do Macro substation before we breakup the statement string before the caret..... Patches are welcome. ;)
Huki:
Hi, been busy for a while...
--- Quote from: ollydbg on January 28, 2014, 10:28:03 am ---
--- Quote from: ollydbg on January 04, 2014, 10:38:49 am ---Today, I have tested the patch: cc_includes_parsing.patch
But I found it cause some GUI hang problem, see my report question about running parser in thread, I guess the reason is:
If you recursively parse the #include directive.
--- Code: --- if (!locked)
CC_LOCKER_TRACK_TT_MTX_LOCK(s_TokenTreeMutex)
//this is a recursive call to Parse() function????
result = thread->Parse();
delete thread;
if (!locked)
CC_LOCKER_TRACK_TT_MTX_UNLOCK(s_TokenTreeMutex)
--- End code ---
So, you hold the s_TokenTreeMutex for a very long time. Some GUI function may try to query information from Tokentree, thus they get hangs.
--- End quote ---
I have a improvement patch to handle this (see attachment). The parser only parses cpp files in the project, recursive call the parse function when it meet the #include directive, the result is quite good.
--- End quote ---
Yes, my cc_includes_parsing patch did cause the UI to hang-up a bit because of the recursive parsing. I just tried your patch which frees up the mutex for a while before recursing, and the result is indeed quite good. Thanks!
Huki:
Any news on my cc_enum_values.patch? I'm attaching it again and the supported test cases in cc_enum_test.patch.
- Uses expression solver to calculate the enum value, expand macro assignments.
- Supports enum assignment to a previous enum (checks under the correct parent).
- If the expression cannot be evaluated (eg, unknown macro), leave it and the next enums blank and don't reset it to zero.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version