Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Code Completion & Workspace
seb_seb0:
--- Quote from: ollydbg on May 12, 2011, 03:45:31 am ---
--- Quote ---In the 1st image, consider the virtual class L3D_IRenderSystem.
L3D_IRenderSystem is defined in the lib, and I use a pointer to it in the main program.
I can see it in the symbol browser, but when I right click on "Find the Declaration of : 'L3D_IRenderSystem'", I get the error message "Not found ..."
--- End quote ---
"Find the Declaration" is just doing a scope match. I wrote this in the wiki, see:
6 Automatic Code Completion
and about debugging cc plugin, there are two kind of tracer
1, if you want to debug the parser, you can simply follow this:
7 Code completion debugging support
2, if you want to see how "find the declaration works", you should enable the
7.4 Debug Smart Sense log output
Note that CC does not do "full preprocessor" and "type check", so it may failed in parsing something. But if the parser is running endlessly, it mostly has a infinite loop bug, this bug should be fixed.
--- End quote ---
Thanks for the info, I will use it, and I will let you know if I find something.
To sum up what has been said, there are 3 bugs :
1 - a problem with namespace scope resolution - see my last post with a minimal test project
2 - a problem of Parser Thread blocked in an endless loop => I will try to see what I can find
3 - a crash problem : for me, it occured when switching to another opened file, by clicking on an editor tab (that means several files are opened).
It did not occured while trying to quit CB.
On the bright side: since the bugs are identified, we can solve them !
Sebastien
killerbot:
--- Quote ---when the "using namespace" clause is defined in the header file, the bug occurs.
--- End quote ---
CC should not fail on that. Agreed, but the only advice I can give you : just don't do this. That is not the intention of namespaces, actually this is killing the entire purpose of namespaces .
See also books of Meyers, Sutter, ...
ollydbg:
--- Quote ---when the "using namespace" clause is defined in the header file, the bug occurs.
The bug does NOT occur when:
1 - the using namespace clause is the cpp file
2 - an explicit scope resolution is done in the source (ex: LIB_NS:: )
--- End quote ---
True, the current implementation has this bug. Mostly because we do NOT expand the #include directive.
In-fact, we have very limited preprocessor directive handling.
We only collect the "using namespace xxx" directive in the current file. So, as you said, if the "using namespace clause" was in other header files, surely they will be ignored, and this bug will occur.
see:6.1 Find the search scope, I have explained the method on how to correct a initial search scope.
BTW: If we do a full preprocessor handling, we are nearly design a full compiler front end. :D
MortenMacFly:
--- Quote from: seb_seb0 on May 12, 2011, 09:42:40 pm --- 2 - a problem of Parser Thread blocked in an endless loop => I will try to see what I can find
--- End quote ---
I finally have a test case for this.
In the attached project, if you inspect the log it never stop parsing the second project. You have to ensure, that you have *one* parser for the whole workspace to reproduce. Notice that both projects are the same, except that the second one compiles/links statically. Thu they use different #defines, but for the same sources (wx). Maybe that's the issue - reminds me to try what happens if I disable the complex macro parsing...
ollydbg:
--- Quote from: MortenMacFly on May 13, 2011, 07:55:44 am ---
--- Quote from: seb_seb0 on May 12, 2011, 09:42:40 pm --- 2 - a problem of Parser Thread blocked in an endless loop => I will try to see what I can find
--- End quote ---
I finally have a test case for this.
In the attached project, if you inspect the log it never stop parsing the second project. You have to ensure, that you have *one* parser for the whole workspace to reproduce. Notice that both projects are the same, except that the second one compiles/links statically. Thu they use different #defines, but for the same sources (wx). Maybe that's the issue - reminds me to try what happens if I disable the complex macro parsing...
--- End quote ---
the attachment zip file has not cpp files in it? did you forget attach them?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version