deb http://apt.jenslody.de/ any cc
deb-src http://apt.jenslody.de/ any cc
Where is the download link for Windows?In the first post by killerbot.
Where is the download link for Windows?In the first post by killerbot.
The 19 September 2010 build is out.
- Windows :
http://prdownload.berlios.de/codeblocks/CB_20100919_rev6608_CC_BRANCH_win32.7z
- Linux :
it should bethanks.
http://prdownload.berlios.de/codeblocks/CB_20100925_rev6634_CC_BRANCH_win32.7z
Editor Open
project data set for /home/xxxxx.h
Top Editor: /home/xxxxx.cpp
** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed
** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed
[New Thread 0xa9bb1b70 (LWP 30027)]
** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed
Caching GCC dir: /usr/include/c++/4.4
Caching GCC dir: /usr/include/c++/4.4/i486-linux-gnu
Caching GCC dir: /usr/include/c++/4.4/backward
Caching GCC dir: /usr/local/include
Caching GCC dir: /usr/lib/gcc/i486-linux-gnu/4.4.3/include
Caching GCC dir: /usr/lib/gcc/i486-linux-gnu/4.4.3/include-fixed
Caching GCC dir: /usr/include
Passing list of files to batch-parser.
Header to parse up-front: '/usr/include/c++/4.4/cstddef'
Add up-front parsing 1 file(s) for project 'xxxxx'...
Add batch-parsing 4979 file(s) for project 'xxxxx'...
Create new parser for project 'xxxxx'
Starting batch parsing for project 'xxxxx'...
Start switch from OnParserStart::ptCreateParser
Switch parser to project 'xxxxx'
[New Thread 0xa93b0b70 (LWP 30032)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa9bb1b70 (LWP 30027)]
0x00000adf in ?? ()
(gdb) bt
#0 0x00000adf in ?? ()
#1 0x00f06698 in wxEvtHandler::AddPendingEvent(wxEvent&) () from /usr/lib/libwx_baseu-2.8.so.0
#2 0x00263e91 in wxPostEvent (this=0xb1c148c) at /usr/include/wx-2.8/wx/event.h:2570
#3 cbThreadPool::TaskDone (this=0xb1c148c) at cbthreadpool.cpp:167
#4 0x002642e4 in cbThreadPool::cbWorkerThread::Entry (this=0xa936000) at cbthreadpool.cpp:236
#5 0x00f058b8 in wxThreadInternal::PthreadStart(wxThread*) () from /usr/lib/libwx_baseu-2.8.so.0
#6 0x00f0591d in wxPthreadStart () from /usr/lib/libwx_baseu-2.8.so.0
#7 0x00f7396e in start_thread (arg=0xa9bb1b70) at pthread_create.c:300
#8 0x01193a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb)
** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed:(
** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed
[New Thread 0xa9bb1b70 (LWP 30027)]
** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed
What is the meaning about this log?Quote** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed:(
** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed
[New Thread 0xa9bb1b70 (LWP 30027)]
** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed
C++ Parser is still parsing files...
C++ Parser is still parsing files...
C++ Parser is still parsing files...
C++ Parser is still parsing files...
C++ Parser is still parsing files...
C++ Parser is still parsing files...
C++ Parser is still parsing files...
C++ Parser is still parsing files...
C++ Parser is still parsing files...
C++ Parser is still parsing files...
I think it is related to gtk/wxgtk, but unfortunately google says nothing special about that message.
I don't remember if I see it earlier but I don't run C::B in console or in gdb very often.
What is the meaning about this log?Quote** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed:(
** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed
[New Thread 0xa9bb1b70 (LWP 30027)]
** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed
I think it is related to gtk/wxgtk, but unfortunately google says nothing special about that message.
I don't remember if I see it earlier but I don't run C::B in console or in gdb very often.
Hi,
I have following segfaults when loading some big project ~800k LOC /
~3000-4000 files (but about 10 files are opened) with C::B version 10.05cc6634-1
from Jens repository (CC branch). I have it usually three times on five C::B starts.
Header to parse up-front: '/usr/include/c++/4.4/cstddef'
Header to parse up-front: '/usr/include/boost/config.hpp'
Header to parse up-front: '/usr/include/boost/filesystem/config.hpp'
Add up-front parsing 3 file(s) for project 'test'...
Add batch-parsing 21641 file(s) for project 'test'...
Create new parser for project 'test'
Starting batch parsing for project 'test'...
What is the meaning about this log?Quote** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed:(
** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed
[New Thread 0xa9bb1b70 (LWP 30027)]
** (codeblocks:29715): CRITICAL **: smooth_draw_flat_box: assertion `width >= -1' failed
I think it is related to gtk/wxgtk, but unfortunately google says nothing special about that message.
I don't remember if I see it earlier but I don't run C::B in console or in gdb very often.
I don't get it here (debian 64-bit unstable/experimental mix).
Errors like this are often caused by gtk2-changes.
Which OS are you on and what is the version of libgtk2 ?
I think I found the cause for the hang and the place, where it happens.@jens:
I will post more informations later.
How can I do that using the Nightly ????? Don't understand your problem.
void testFunc();
void TestFunc();
tes| // only show "testFunc" now
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
else if (!tk->m_Args.IsEmpty())
AAA is replaced to BBB
Then BBB is replaced to AAA
...AAA is replaced to BBB
...BBB is replaced to AAA
...
With every loop the real length of m_Buffer grows by one (that's the cause for the great amount of memory used in my test).Macro expansion is just replace some characters in the m_Buffer.
xxxxxxxxxAAAA(u,v)yyyyyyyyy
xxxNNNNNNNNNNNNNNNyyyyyyyyy
NNNNNNNNNNNNNNNNNNNNNNyyyyyyyyy
It's in fact an endless loop cc runs in:It shoud be fixed by this patch.CodeHappens in tokenizer.cpp in CalcConditionExpression after call of ReplaceBufferForReparse inReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)
The replaced actual context are '_AC(x, UL)'.
ReplaceBufferForReparse() : <FROM> _AC(x,(x)<TO>_AC(x, UL)
ReplaceBufferForReparse() : <FROM> UL<TO>(x)Code.else if (!tk->m_Args.IsEmpty())
AAA is replaced to BBBYes, like this, AAA is macro, and BBB is argument. I can't write a sample too.
Then BBB is replaced to AAA
...AAA is replaced to BBB
...BBB is replaced to AAA
...
it should be a bug in Macro expansion related code. some infinite recursive macro replacement happens. likeQuoteAAA is replaced to BBB
Then BBB is replaced to AAA
...AAA is replaced to BBB
...BBB is replaced to AAA
...QuoteWith every loop the real length of m_Buffer grows by one (that's the cause for the great amount of memory used in my test).Macro expansion is just replace some characters in the m_Buffer.CodexxxxxxxxxAAAA(u,v)yyyyyyyyy
For example, the above is a char Array m_Buffer, then "AAAA(u,v)" need to do a Macro expansion to some other text. So, we just do a "backward" text replace, so that, after replacement, The last replacement char was ")" in "AAAA(u,v)" (We say it as an entry point), so the text becomes:CodexxxNNNNNNNNNNNNNNNyyyyyyyyy
Note that "NNNNNNNNNNNN" is some macro expansion text. then the m_TokenIndex was moved backward to the beginning of the text.
if the macro expansion result text is small enough, then m_Buffer's length do not need to change.
The situation when our m_Buffer's length need to be change is that the macro expansion text is too long, so the buffer before "entry point" can not hold the new text, this way, m_Buffer's length will adjusted. like:CodeNNNNNNNNNNNNNNNNNNNNNNyyyyyyyyy
Hope this helps to find the bug.
@ Loaden:
I test the patch and give you feedback.
ReplaceBufferForReparse() : <FROM>printf<TO>printk
ReplaceBufferForReparse() : <FROM>printk<TO>printf
This seems very strange! Jens, could you give me more information?@ Loaden:
I test the patch and give you feedback.
First endless-loop seems to be fixed, now we get one some lines later.Codetk->m_Type is printf and token is printk and vice versa.ReplaceBufferForReparse() : <FROM>printf<TO>printk
ReplaceBufferForReparse() : <FROM>printk<TO>printf
Can this be handled in ReplaceBufferForReparse, so it only has to be done in one place ?
ReplaceBufferForReparse() : <FROM>printk<TO>printf
ReplaceBufferForReparse() : <FROM>( printf<TO>(args...)
ReplaceBufferForReparse() : <FROM>args...)(args)<TO> printk(args)
ReplaceBufferForReparse() : <FROM>printk<TO>printf
ReplaceBufferForReparse() : <FROM>( printf<TO>(args...)
ReplaceBufferForReparse() : <FROM>args...)(args)<TO> printk(args)
ReplaceBufferForReparse() : <FROM>printk<TO>printf
ReplaceBufferForReparse() : <FROM>( printf<TO>(args...)
Thanks! This code lead CB endless loop.@ Loaden:
I test the patch and give you feedback.
First endless-loop seems to be fixed, now we get one some lines later.Codetk->m_Type is printf and token is printk and vice versa.ReplaceBufferForReparse() : <FROM>printf<TO>printk
ReplaceBufferForReparse() : <FROM>printk<TO>printf
Can this be handled in ReplaceBufferForReparse, so it only has to be done in one place ?
#define AAA(x) BBB(x)
#define BBB(y) AAA(y)
#if AAA(1) && BBB(2)
void fly();
#else
void good();
#endif
Thanks! This code lead CB endless loop.
I will fix it soon.Code#define AAA(x) BBB(x)
#define BBB(y) AAA(y)
#if AAA(1) && BBB(2)
void fly();
#else
void good();
#endif
But we still have to avoid all possible infinite loop. :lol:Thanks! This code lead CB endless loop.
I will fix it soon.Code#define AAA(x) BBB(x)
#define BBB(y) AAA(y)
#if AAA(1) && BBB(2)
void fly();
#else
void good();
#endif
But the code above does not compile. :D
Thanks! This code lead CB endless loop.
I will fix it soon.Code#define AAA(x) BBB(x)
#define BBB(y) AAA(y)
#if AAA(1) && BBB(2)
void fly();
#else
void good();
#endif
But the code above does not compile. :D
The kernel code surely does not compile also (all files added to a C::B project without running any configuration-scripts and without using makefiles), but it leads to an endless loop when parsing the sources and that should (of course) not happen, even if the code has errors.
But we still have to avoid all possible infinite loop. :lol:
Maybe, we could limit the macro expansion level to avoid the recursive infinite loop.Agreed! This is a good idea. :D
The kernel code surely does not compile also (all files added to a C::B project without running any configuration-scripts and without using makefiles), but it leads to an endless loop when parsing the sources and that should (of course) not happen, even if the code has errors.Hi, Jens, Please trying this patch?
The kernel code surely does not compile also (all files added to a C::B project without running any configuration-scripts and without using makefiles), but it leads to an endless loop when parsing the sources and that should (of course) not happen, even if the code has errors.Hi, Jens, Please trying this patch?
cc debug-info: http://apt.jenslody.de/cc/cc_debug.7z (http://apt.jenslody.de/cc/cc_debug.7z)Thank Jens! I will look into it carefully.
As written before, the test-project is generated from the (debian) linux-kernel sources, revision 2.6.29.
No build-options or defines, just all files from sources added to an empty project.
Another issue (not related to this), is that the symboslbrowser stays empty, if the project is opened without any shown editor.Confirmed!
After opening any file the symbols-browser gets filled.
bool Parser::Done()
{
wxCriticalSectionLocker locker(s_ParserCritical);
bool done = m_UpFrontHeaders.IsEmpty()
&& m_SystemUpFrontHeaders.IsEmpty()
&& m_BatchParseFiles.IsEmpty()
&& m_PredefinedMacros.IsEmpty()
&& !m_NeedMarkFileAsLocal // When parsing end, this value be true always in Linux/GCC4.5.1!
&& m_PoolTask.empty()
&& m_Pool.Done();
return done;
}
Parsing takes a little more than 28 minutes, that's very long, but I get more than 1 million tokens.1, the batch parsing time is too long:
#define AAA(x) BBB(x)
#define BBB(y) AAA(y)
#if AAA(1) && BBB(2)
void fly();
#else
void good();
#endif
And it seems parsing is not correct, I get some strange tokens in symbol browser (see the attached picture).2. parsing error, wrong tokens:
There seem to be two instances of NativeParser with two different variables for m_Parser, one parser returns true for Done() and the other one returns false.Another issue (not related to this), is that the symboslbrowser stays empty, if the project is opened without any shown editor.Confirmed!
After opening any file the symbols-browser gets filled.
EDIT: It's can confirmed only Linux, and in Windows, no have this issue.
Here:Quotebool Parser::Done()
{
wxCriticalSectionLocker locker(s_ParserCritical);
bool done = m_UpFrontHeaders.IsEmpty()
&& m_SystemUpFrontHeaders.IsEmpty()
&& m_BatchParseFiles.IsEmpty()
&& m_PredefinedMacros.IsEmpty()
&& !m_NeedMarkFileAsLocal // When parsing end, this value be true always in Linux/GCC4.5.1!
&& m_PoolTask.empty()
&& m_Pool.Done();
return done;
}
please have a look at this. It seems a little regression got introduced : http://forums.codeblocks.org/index.php/topic,13413.msg90463.html#msg90463OK, I will look into it, and hopefully fixed soon.
There seem to be two instances of NativeParser with two different variables for m_Parser, one parser returns true for Done() and the other one returns false.Fixed in r6665, thanks!
The one that returns true is called in CodeCompletion::OnParserEnd and the other one is the one that catches the PARSER_END event in NativeParser::OnParserEnd .
Nevertheless, there are tokens that contain (or even begin with) whitespace, that means these tokens are invaild, so they could be (should be ?) securely removed.I found a reason, in file "/home/jens/kernel-tmp/linux-source-2.6.29/sound/aoa/codecs/tas.c", there has a struct named tas:
struct tas {
struct aoa_codec codec;
struct i2c_client *i2c;
u32 mute_l:1, mute_r:1 ,
controls_created:1 ,
drc_enabled:1,
hw_enabled:1;
u8 cached_volume_l, cached_volume_r;
u8 mixer_l[3], mixer_r[3];
u8 bass, treble;
u8 acr;
int drc_range;
/* protects hardware access against concurrency from
* userspace when hitting controls and during
* codec init/suspend/resume */
struct mutex mtx;
};
preprocessor #define tas(ptr) (xchg((ptr),1)) [186,42]So, we will get a error parse result:
/home/jens/kernel-tmp/linux-source-2.6.29/sound/aoa/codecs/tas.c
preprocessor #define PFX DEVNAME ": " [1,77]
class class (xchg((ptr),1)) {...} [83,83]
variable u32 (xchg((ptr),1))::mute_l [86,0]
variable u32 (xchg((ptr),1))::mute_r [86,0]
variable u32 (xchg((ptr),1))::controls_created [87,0]
variable u32 (xchg((ptr),1))::drc_enabled [88,0]
variable u32 (xchg((ptr),1))::hw_enabled [89,0]
variable u32u8 (xchg((ptr),1))::cached_volume_l [90,0]
variable u32u8 (xchg((ptr),1))::cached_volume_r [90,0]
variable u8 (xchg((ptr),1))::mixer_l [91,0]
variable u8 (xchg((ptr),1))::mixer_r [91,0]
variable u8 (xchg((ptr),1))::bass [92,0]
variable u8 (xchg((ptr),1))::treble [92,0]
variable u8 (xchg((ptr),1))::acr [93,0]
#define tas(ptr) (xchg((ptr),1))
struct tas {
struct aoa_codec codec;
struct i2c_client *i2c;
u32 mute_l:1, mute_r:1 ,
controls_created:1 ,
drc_enabled:1,
hw_enabled:1;
u8 cached_volume_l, cached_volume_r;
u8 mixer_l[3], mixer_r[3];
u8 bass, treble;
u8 acr;
int drc_range;
/* protects hardware access against concurrency from
* userspace when hitting controls and during
* codec init/suspend/resume */
struct mutex mtx;
};
Nevertheless, there are tokens that contain (or even begin with) whitespace, that means these tokens are invaild, so they could be (should be ?) securely removed.This issue shoud be fixed in r6670. :D
DoParse() : Loop:m_Str='', token='dma_addr_t'
ReadParentheses(): (* map_single), line=355
HandleMacro() : Adding token 'dma_addr_t' (peek='(* map_single)')
DoAddToken() : Found token (parent).
GetActualTokenType() : Searching within m_Str=''
GetActualTokenType() : Compensated m_Str=''
GetActualTokenType() : Returning ''
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'dma_addr_t' (490410), type '', actual ''. Parent is esp_driver_ops (490406)
The replaced actual context are 'dma_addr_t'.
ReplaceBufferForReparse() : <FROM>dma_addr_t<TO>dma_addr_t
DoParse() : Loop:m_Str='', token='dma_addr_t'
ReadParentheses(): (* map_single), line=355
HandleMacro() : Adding token 'dma_addr_t' (peek='(* map_single)')
DoAddToken() : Found token (parent).
GetActualTokenType() : Searching within m_Str=''
GetActualTokenType() : Compensated m_Str=''
GetActualTokenType() : Returning ''
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'dma_addr_t' (490410), type '', actual ''. Parent is esp_driver_ops (490406)
The replaced actual context are 'dma_addr_t'.
ReplaceBufferForReparse() : <FROM>dma_addr_t<TO>dma_addr_t
Next endless loop, this time with linux kernel-sources 2.6.35.Fixed in r6671.
Next endless loop, this time with linux kernel-sources 2.6.35.Fixed in r6671.
Thanks!
Project 'test' parsing stage done (30453 total parsed files, 1347032 tokens in 42 minute(s), 24.656 seconds).
Works now:CodeProject 'test' parsing stage done (30453 total parsed files, 1347032 tokens in 42 minute(s), 24.656 seconds).
And also the annoying issue, that the symbols-browser is initially empty if no file is opened, seems to be fixed !Yes, This issue fixed in r6665.
* cc_branch: fix parser init error, lead class browser can not correctly refreshed
-------------------------------
M : /branches/codecompletion_refactoring/src/plugins/codecompletion/nativeparser.cpp
Works now:Hi, Jens, About the batch parsing time, could you shut off the debug log trace, and trying again?CodeProject 'test' parsing stage done (30453 total parsed files, 1347032 tokens in 42 minute(s), 24.656 seconds).
#define CC_TOKENIZER_DEBUG_OUTPUT 0If use debug log, will lead batch parsing as long time.
#define CC_PARSERTHREAD_DEBUG_OUTPUT 0
...
Works now:CodeProject 'test' parsing stage done (30453 total parsed files, 1347032 tokens in 42 minute(s), 24.656 seconds).
Hi, jens, Did you remember how long will the batch parse take to parse the whole Linux source, when you did this last time(If I remember correct, maybe one year ago)?
I can do, but it will not make such a big difference I guess, because I have an additional static variable inside the ifdef to switch on debug output while running debugger (by changing the value from false to true).Works now:Hi, Jens, About the batch parsing time, could you shut off the debug log trace, and trying again?CodeProject 'test' parsing stage done (30453 total parsed files, 1347032 tokens in 42 minute(s), 24.656 seconds).
Here:Quote#define CC_TOKENIZER_DEBUG_OUTPUT 0If use debug log, will lead batch parsing as long time.
#define CC_PARSERTHREAD_DEBUG_OUTPUT 0
...
There may be a large number of duplicate tokens, tokens will not be in direct proportion with the time.Works now:CodeProject 'test' parsing stage done (30453 total parsed files, 1347032 tokens in 42 minute(s), 24.656 seconds).
Hi, jens, Did you remember how long will the batch parse take to parse the whole Linux source, when you did this last time(If I remember correct, maybe one year ago)?
No, and it would not give any answers about incfreasing or decreasing parse time, because this time I parsed 2.6.35 kernel sources, the last time it was 2.6.29 with only 21k files and a little more than a million tokens, but I will test with current trunk and give you feedback.
InitTokenizer() : m_Filename='/usr/include/bits/time.h', m_FileSize=2866.
Parse() : Parsing '/usr/include/bits/time.h'
DoParse() : Loop:m_Str='', token='#'
DoParse() : Loop:m_Str='', token='#'
DoAddToken() : Created token='_STRUCT_TIMEVAL', file_idx=12732, line=70, ticket=
GetActualTokenType() : Searching within m_Str='1'
GetActualTokenType() : Compensated m_Str='1'
GetActualTokenType() : Found '1'
DoAddToken() : Prepending ''
DoParse() : Loop:m_Str='', token='#'
HandleIncludes() : Found include file 'bits/types.h'
DoParse() : Loop:m_Str='', token='struct'
HandleClass() : Found class 'timeval'
DoAddToken() : Created token='timeval', file_idx=12732, line=75, ticket=
GetActualTokenType() : Searching within m_Str=''
GetActualTokenType() : Compensated m_Str=''
GetActualTokenType() : Returning ''
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'timeval' (353789), type '', actual ''. Parent is (-1)
DoParse() : Loop:m_Str='', token='__time_t'
DoParse() : Loop:m_Str='__time_t ', token='tv_sec'
DoAddToken() : Created token='tv_sec', file_idx=12732, line=77, ticket=
GetActualTokenType() : Searching within m_Str='__time_t'
GetActualTokenType() : Compensated m_Str='__time_t'
GetActualTokenType() : Found '__time_t'
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'tv_sec' (353790), type '__time_t', actual '__time_t'. Parent is timeval (353789)
DoParse() : Loop:m_Str='__time_t', token=';'
DoParse() : Loop:m_Str='', token='__suseconds_t'
DoParse() : Loop:m_Str='__suseconds_t ', token='tv_usec'
DoAddToken() : Created token='tv_usec', file_idx=12732, line=78, ticket=
GetActualTokenType() : Searching within m_Str='__suseconds_t'
GetActualTokenType() : Compensated m_Str='__suseconds_t'
GetActualTokenType() : Found '__suseconds_t'
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'tv_usec' (353791), type '__suseconds_t', actual '__suseconds_t'. Parent is timeval (353789)
DoParse() : Loop:m_Str='__suseconds_t', token=';'
DoParse() : Loop:m_Str='', token='}'
InitTokenizer() : m_Filename='/usr/include/bits/dirent.h', m_FileSize=1609.
Parse() : Parsing '/usr/include/bits/dirent.h'
DoParse() : Loop:m_Str='', token='struct'
HandleClass() : Found class 'dirent'
C++ Parser is still parsing files...
C++ Parser is still parsing files...
C++ Parser is still parsing files...
Tasks: 143 total, 1 running, 142 sleeping, 0 stopped, 0 zombie
Cpu(s): 60.8%us, 3.0%sy, 0.0%ni, 36.0%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2062772k total, 1969520k used, 93252k free, 145608k buffers
Swap: 2104476k total, 9292k used, 2095184k free, 664664k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15947 1234 20 0 824m 573m 34m S 102 28.5 19:55.35 codeblocks
trunk:
[...]
33115 files loaded
Done loading project in 84084ms
[...]
Parsing stage done (33919 total parsed files, 1193078 tokens in 1 minute(s), 59.116 seconds).
"Pure" cc:
[...]
33115 files loaded
Done loading project in 82294ms
[...]
DoAddToken() : Created token='__xl', file_idx=761, line=27, ticket=
GetActualTokenType() : Searching within m_Str='"r0"'
GetActualTokenType() : Compensated m_Str='"r0"'
GetActualTokenType() : Found ''
DoAddToken() : Prepending ''
DoParse() : Loop:m_Str='', token='#'
wxString Tokenizer::ReadToEOL(bool, bool) : line=28, CurrentChar='
', PreviousChar='"', NextChar='#', nestBrace(1)
ReadToEOL(): (END) We are now at line 28, CurrentChar='
', PreviousChar='"', NextChar='#'
ReadToEOL():
DoAddToken() : Created token='__xh', file_idx=761, line=28, ticket=
GetActualTokenType() : Searching within m_Str='"r1"'
GetActualTokenType() : Compensated m_Str='"r1"'
GetActualTokenType() : Found ''
DoAddToken() : Prepending ''
HandleConditionPreprocessor() : #endif at line = 29
bool Tokenizer::SkipToEOL(bool) : line=29, CurrentChar='
', PreviousChar='f', NextChar='
', nestBrace(0)
SkipToEOL(): (END) We are now at line 29, CurrentChar='
', PreviousChar='f', NextChar='
'
DoParse() : Loop:m_Str='', token='#'
ReadParentheses(): (n, base), line=31
wxString Tokenizer::ReadToEOL(bool, bool) : line=31, CurrentChar=' ', PreviousChar=')', NextChar=' ', nestBrace(1)
ReadToEOL(): (END) We are now at line 47, CurrentChar='
', PreviousChar=')', NextChar='
'
ReadToEOL(): ({ register unsigned int __base asm("r4") = base; register unsigned long long __n asm("r0") = n; register unsigned long long __res asm("r2"); register unsigned int __rem asm(__xh); asm( __asmeq("%0", __xh) __asmeq("%1", "r2") __asmeq("%2", "r0") __asmeq("%3", "r4") "bl __do_div64" : "=r" (__rem), "=r" (__res) : "r" (__n), "r" (__base) : "ip", "lr", "cc"); n = __res; __rem; })
DoAddToken() : Created token='__do_div_asm', file_idx=761, line=31, ticket=
GetActualTokenType() : Searching within m_Str=' ({ register unsigned int __base asm("r4") = base; register unsigned long long __n asm("r0") = n; register unsigned long long __res asm("r2"); register unsigned int __rem asm(__xh); asm( __asmeq("%0", __xh) __asmeq("%1", "r2") __asmeq("%2", "r0") __asmeq("%3", "r4") "bl __do_div64" : "=r" (__rem), "=r" (__res) : "r" (__n), "r" (__base) : "ip", "lr", "cc"); n = __res; __rem; })'
GetActualTokenType() : Compensated m_Str=' ({ register unsigned int __base asm("r4") = base; register unsigned long long __n asm("r0") = n; register unsigned long long __res asm("r2"); register unsigned int __rem asm(__xh); asm( __asmeq("%0", __xh) __asmeq("%1", "r2") __asmeq("%2", "r0") __asmeq("%3", "r4") "bl __do_div64" :"=r" (__rem), "=r" (__res) :"r" (__n), "r" (__base) :"ip", "lr", "cc"); n = __res; __rem; })'
GetActualTokenType() : Found ''
DoAddToken() : Prepending ''
HandleConditionPreprocessor() : #if at line = 49
bool Tokenizer::SkipToEOL(bool) : line=49, CurrentChar=' ', PreviousChar='f', NextChar='_', nestBrace(0)
SkipToEOL(): (END) We are now at line 49, CurrentChar='
', PreviousChar='4', NextChar='
'
CalcConditionExpression() : exp.GetStatus() : 1, exp.GetResult() : 0
HandleConditionPreprocessor() : #elif at line = 61
bool Tokenizer::SkipToEOL(bool) : line=61, CurrentChar=' ', PreviousChar='f', NextChar='_', nestBrace(0)
SkipToEOL(): (END) We are now at line 61, CurrentChar='
', PreviousChar='4', NextChar='
'
CalcConditionExpression() : exp.GetStatus() : 1, exp.GetResult() : 1
DoParse() : Loop:m_Str='', token='#'
HandleIncludes() : Found include file 'asm/bug.h'
DoParse() : Loop:m_Str='', token='#'
ReadParentheses(): (n, base), line=73
wxString Tokenizer::ReadToEOL(bool, bool) : line=73, CurrentChar=' ', PreviousChar=')', NextChar=' ', nestBrace(1)
ReadToEOL(): (END) We are now at line 211, CurrentChar='
', PreviousChar=')', NextChar='
'
thanks jens for the test.My guess:
From the "pure CC" log file before crash, I can't find any thing wrong, it seems the log was correct (parserthread works fine before crash).
So, the problem should happened before the crash.
@loaden, Maybe, we could add an option to "disable the macro expansion", then see if it still hangs or crash in this case.
If I run it from commandline, it eats up all my memory (up to ~4GB) and after some tome it crashes with an X-window error (resource temproary unavailable), if I run it through debugger it crashes with a segfault in wxPostEVent, if it tries to send a TaskDone-event.
Maybe the size of the used buffers should also be traced.Yes, I'll checking carefully.
Project 'linux' parsing stage done (27214 total parsed files, 1342720 tokens in 17 minute(s), 37.094 seconds).
Project 'linux' parsing stage done (27214 total parsed files, 1258851 tokens in 8 minute(s), 54.969 seconds).
Project 'test' parsing stage done (21827 total parsed files, 1011919 tokens in 22 minute(s), 2.405 seconds).
Project 'test' parsing stage done (21827 total parsed files, 951347 tokens in 3 minute(s), 58.764 seconds).
Project 'test' parsing stage done (30453 total parsed files, 1343328 tokens in 41 minute(s), 5.657 seconds).
Project 'test' parsing stage done (30453 total parsed files, 1259360 tokens in 4 minute(s), 50.464 seconds).
Index: src/plugins/codecompletion/parser/token.cpp
===================================================================
--- src/plugins/codecompletion/parser/token.cpp (Revision 6677)
+++ src/plugins/codecompletion/parser/token.cpp (Arbeitskopie)
@@ -1027,10 +1027,10 @@
}
}
-#if CC_TOKEN_DEBUG_OUTPUT
- TRACE(_T("RecalcInheritanceChain() : First iteration took : %ld ms"), sw.Time());
- sw.Start();
-#endif
+//#if CC_TOKEN_DEBUG_OUTPUT
+// TRACE(_T("RecalcInheritanceChain() : First iteration took : %ld ms"), sw.Time());
+// sw.Start();
+//#endif
// recalc
TokenIdxSet result;
@@ -1057,16 +1057,20 @@
{
Token* anc_token = at(*it);
if (anc_token)
+ {
TRACE(_T("RecalcInheritanceChain() : + %s"), anc_token->m_Name.wx_str());
+ }
else
+ {
TRACE(_T("RecalcInheritanceChain() : + NULL?!"));
+ }
}
}
#endif
-#if CC_TOKEN_DEBUG_OUTPUT
- TRACE(_T("RecalcInheritanceChain() : Second iteration took : %ld ms"), sw.Time());
-#endif
+//#if CC_TOKEN_DEBUG_OUTPUT
+// TRACE(_T("RecalcInheritanceChain() : Second iteration took : %ld ms"), sw.Time());
+//#endif
TRACE(_T("RecalcInheritanceChain() : Full inheritance calculated."));
}
@@ -1215,9 +1219,13 @@
{
Token* anc_token = at(*it);
if (anc_token)
+ {
TRACE(_T("RecalcData() : + %s"), anc_token->m_Name.wx_str());
+ }
else
+ {
TRACE(_T("RecalcData() : + NULL?!"));
+ }
}
}
#endif
Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (Revision 6677)
+++ src/plugins/codecompletion/parser/parserthread.cpp (Arbeitskopie)
@@ -1197,8 +1197,10 @@
newToken = new(std::nothrow) Token(newname, m_FileIdx, line, ++m_pTokensTree->m_TokenTicketCount);
if (newToken)
+ {
TRACE(_T("DoAddToken() : Created token='%s', file_idx=%d, line=%d, ticket="), newname.wx_str(),
m_FileIdx, line, m_pTokensTree->m_TokenTicketCount);
+ }
else
{
--m_pTokensTree->m_TokenTicketCount;
By the way, the following patch is needed to make C::B compile without a warning if CC_XXX_DEBUG_OUTPUT is set to 2.Fixed in r6678.
I did not change all places (should all be checked I think), only the places which lead to a compiler warning:
The second time (parsing without) was done immediately after closing the project, so that most of the files are still in the systems hdd-buffer.No, because the ParserThread instance of these files does not created.
Parsing the linux-kernel 2.6.35 only works with debug-output enebaled and redirected to a file (C::B uses up to 2.5 GB of memory and did not release it at project unload).I can not reproduce in the Windows system, you can help find which file is causing the problem?
Using from within C::B or diretcly from console, either crashes C::B or freezes the whole system.
#include <ole2.h>
...
VARIANT param;
VariantInit(¶m);
param./*Ctrl-Space show only dblVal*/
CB_CC_BRANCH_r6675 can't parce ole2.h with MinGWSorry, this is too complex, my personal opinion, not yet plan to support it.Code#include <ole2.h>
...
VARIANT param;
VariantInit(¶m);
param./*Ctrl-Space show only dblVal*/
CB_CC_BRANCH_r6675 can't parce ole2.h with MinGWSorry, this is too complex, my personal opinion, not yet plan to support it.Code#include <ole2.h>
...
VARIANT param;
VariantInit(¶m);
param./*Ctrl-Space show only dblVal*/
The second time (parsing without) was done immediately after closing the project, so that most of the files are still in the systems hdd-buffer.No, because the ParserThread instance of these files does not created.
I see, thanks!The second time (parsing without) was done immediately after closing the project, so that most of the files are still in the systems hdd-buffer.No, because the ParserThread instance of these files does not created.
...I'm confused about your discussion. Jens says that the second batch parse takes much less time because of the system's cache for source files.
@killerbotFixed in r6687, so, I think we are ready now. :D
Could you publish a CODECOMPLETION BRANCH nightly build in this weekend?
We add some feature, and fixed some bugs of reported in forum.
Thanks a lot! :D
EDIT: Please waiting, found a new issue, we need a whole day for test. :(
Hi,Could you trying r6690?
I'm testing C::B CC_branch on another big project - OpenOffice and after ~20 minutes CC parser is hanging on:CodeInitTokenizer() : m_Filename='/usr/include/bits/time.h', m_FileSize=2866.
Parse() : Parsing '/usr/include/bits/time.h'
DoParse() : Loop:m_Str='', token='#'
DoParse() : Loop:m_Str='', token='#'
DoAddToken() : Created token='_STRUCT_TIMEVAL', file_idx=12732, line=70, ticket=
GetActualTokenType() : Searching within m_Str='1'
GetActualTokenType() : Compensated m_Str='1'
GetActualTokenType() : Found '1'
DoAddToken() : Prepending ''
DoParse() : Loop:m_Str='', token='#'
HandleIncludes() : Found include file 'bits/types.h'
DoParse() : Loop:m_Str='', token='struct'
HandleClass() : Found class 'timeval'
DoAddToken() : Created token='timeval', file_idx=12732, line=75, ticket=
GetActualTokenType() : Searching within m_Str=''
GetActualTokenType() : Compensated m_Str=''
GetActualTokenType() : Returning ''
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'timeval' (353789), type '', actual ''. Parent is (-1)
DoParse() : Loop:m_Str='', token='__time_t'
DoParse() : Loop:m_Str='__time_t ', token='tv_sec'
DoAddToken() : Created token='tv_sec', file_idx=12732, line=77, ticket=
GetActualTokenType() : Searching within m_Str='__time_t'
GetActualTokenType() : Compensated m_Str='__time_t'
GetActualTokenType() : Found '__time_t'
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'tv_sec' (353790), type '__time_t', actual '__time_t'. Parent is timeval (353789)
DoParse() : Loop:m_Str='__time_t', token=';'
DoParse() : Loop:m_Str='', token='__suseconds_t'
DoParse() : Loop:m_Str='__suseconds_t ', token='tv_usec'
DoAddToken() : Created token='tv_usec', file_idx=12732, line=78, ticket=
GetActualTokenType() : Searching within m_Str='__suseconds_t'
GetActualTokenType() : Compensated m_Str='__suseconds_t'
GetActualTokenType() : Found '__suseconds_t'
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'tv_usec' (353791), type '__suseconds_t', actual '__suseconds_t'. Parent is timeval (353789)
DoParse() : Loop:m_Str='__suseconds_t', token=';'
DoParse() : Loop:m_Str='', token='}'
InitTokenizer() : m_Filename='/usr/include/bits/dirent.h', m_FileSize=1609.
Parse() : Parsing '/usr/include/bits/dirent.h'
DoParse() : Loop:m_Str='', token='struct'
HandleClass() : Found class 'dirent'
C++ Parser is still parsing files...
C++ Parser is still parsing files...
C++ Parser is still parsing files...CodeTasks: 143 total, 1 running, 142 sleeping, 0 stopped, 0 zombie
Cpu(s): 60.8%us, 3.0%sy, 0.0%ni, 36.0%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2062772k total, 1969520k used, 93252k free, 145608k buffers
Swap: 2104476k total, 9292k used, 2095184k free, 664664k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15947 1234 20 0 824m 573m 34m S 102 28.5 19:55.35 codeblocks
// EDIT: C::B CC branch rev 6671
Could you trying r6690?
Loading project files...
23587 files loaded
Done loading project in 66327ms
Project's base path: /home/lukaszg/projekty/openoffice/
Project's common toplevel path: /home/lukaszg/projekty/openoffice/
[New Thread 0xa8e53b70 (LWP 21390)]
Caching GCC dir: /usr/include/c++/4.5.1
Caching GCC dir: /usr/include/c++/4.5.1/i686-pc-linux-gnu
Caching GCC dir: /usr/include/c++/4.5.1/backward
Caching GCC dir: /usr/local/include
Caching GCC dir: /usr/lib/gcc/i686-pc-linux-gnu/4.5.1/include
Caching GCC dir: /usr/lib/gcc/i686-pc-linux-gnu/4.5.1/include-fixed
Caching GCC dir: /usr/include
Passing list of files to batch-parser.
Header to parse up-front: '/usr/include/c++/4.5.1/cstddef'
Header to parse up-front: '/usr/include/boost/config.hpp'
Header to parse up-front: '/usr/include/boost/filesystem/config.hpp'
Header to parse up-front: '/home/lukaszg/projekty/openoffice/embedserv/source/inc/stdafx.h'
Add up-front parsing 4 file(s) for project 'openoffice'...
Add batch-parsing 12303 file(s) for project 'openoffice'...
Create new parser for project 'openoffice'
EnvVars: Obtained 'default' as active envvar set from config.
EnvVars: Set 'default' will not be applied (already active).
Starting batch parsing for project 'openoffice'...
[New Thread 0xa8652b70 (LWP 21395)]
Project 'openoffice' parsing stage done (13394 total parsed files, 403357 tokens in 1 minute(s), 46.055 seconds).
#include <
#include "
/usr/include
/usr/include/boost
/usr/include/libxml2
yes, this delay is already present for so time now, I can confirm ;-)Because there has too many system headers, and seems need a fast IO system. :)
yes, this delay is already present for so time now, I can confirm ;-)Because there has too many system headers, and seems need a fast IO system. :)
And now, I have not good idea. :(
#include "
Yes, use std::map<wxString, std::list<wxString> > to save all system headers.yes, this delay is already present for so time now, I can confirm ;-)Because there has too many system headers, and seems need a fast IO system. :)
And now, I have not good idea. :(
I don't know - maybe C::B could use some kind of "memory cache" for global / project include file names
- on C::B start one thread could insert global includes file names into some std::map<filename, path>(or maybe other container),
and when user open some project another thread could insert per project file names into same container?
//Edit: And when user write:CodeC::B will use that "cache"?#include "
Project 'test' parsing stage done (21821 total parsed files, 910203 tokens in 3 minute(s), 11.931 seconds).
Project 'test' parsing stage done (30447 total parsed files, 1313354 tokens in 6 minute(s), 54.779 seconds).
I am just compiling it on my server, to update the cc-repo.:D Thanks!
yes, this delay is already present for so time now, I can confirm ;-)Hi, killerbot, Could you have a trying r6707.
Revision 6707 works really fast with #include's :Dyes, this delay is already present for so time now, I can confirm ;-)Hi, killerbot, Could you have a trying r6707.
And post the debug log in here?
Thanks!
Get include file count is 2, use time is 1
Get include file count is 31006, use time is 57
Revision 6707 works really fast with #include's :Dyes, this delay is already present for so time now, I can confirm ;-)Hi, killerbot, Could you have a trying r6707.
And post the debug log in here?
Thanks!
// Edit:
include with "Codeinclude with <Get include file count is 2, use time is 1
CodeGet include file count is 31006, use time is 57
#include " --> worked very fast, but several includes missingAll code in here:
#include < --> still rather slow [and at the start I always have a lot of entries like this : /32/32/32/32/32/32/32....]
// Do the code completion when we enter:Almost all of the time is spent in the AutoCompShow call.
// #include "| or #include <|
void CodeCompletion::CodeCompleteIncludes()
{
wxStopWatch sw;
if (!IsAttached() || !m_InitDone)
return;
cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
if (!ed)
return;
const wxString curFile(ed->GetFilename());
const wxString curPath(wxFileName(curFile).GetPath());
wxArrayString buildTargets;
cbProject* project = m_NativeParser.GetProjectByParser(&m_NativeParser.GetParser());
ProjectFile* pf = project ? project->GetFileByFilename(curFile, false) : 0;
if (pf)
buildTargets = pf->buildTargets;
FileType ft = FileTypeOf(ed->GetShortName());
if ( ft != ftHeader && ft != ftSource) // only parse source/header files
return;
int pos = ed->GetControl()->GetCurrentPos();
int lineStartPos = ed->GetControl()->PositionFromLine(ed->GetControl()->GetCurrentLine());
wxString line = ed->GetControl()->GetLine(ed->GetControl()->GetCurrentLine());
line.Trim();
if (line.IsEmpty() || !TestIncludeLine(line))
return;
bool useSystemHeaders = false;
int keyPos = line.Find(_T('"'));
if (keyPos == wxNOT_FOUND)
{
useSystemHeaders = true;
keyPos = line.Find(_T('<'));
}
if (keyPos == wxNOT_FOUND || keyPos > pos - lineStartPos)
return;
++keyPos;
// now, we are after the quote prompt
wxString filename = line.SubString(keyPos, pos - lineStartPos - keyPos);
filename.Replace(_T("\\"), _T("/"), true);
// fill a list of matching files
StringSet files;
// #include <|
if (m_CCSystemHeaderFiles && useSystemHeaders)
{
wxCriticalSectionLocker locker(s_HeadersCriticalSection);
wxArrayString& incDirs = GetSystemIncludeDirs(&m_NativeParser.GetParser(),
project ? project->GetModified() : true);
for (size_t i = 0; i < incDirs.GetCount(); ++i)
{
SystemHeadersMap::iterator it = m_SystemHeadersMap.find(incDirs);
if (it != m_SystemHeadersMap.end())
{
const StringSet& headers = it->second;
for (StringSet::iterator it = headers.begin(); it != headers.end(); ++it)
files.insert(*it);
}
}
}
// #include "|
if (!useSystemHeaders && project)
{
const wxArrayString localIncludeDirs = GetLocalIncludeDirs(project, buildTargets);
for (int i = 0; i < project->GetFilesCount(); ++i)
{
ProjectFile* pf = project->GetFile(i);
if (pf && FileTypeOf(pf->relativeFilename) == ftHeader)
{
wxString file = pf->file.GetFullPath();
if (file.Find(filename) != wxNOT_FOUND)
{
wxString header;
for (size_t j = 0; j < localIncludeDirs.GetCount(); ++j)
{
const wxString& dir = localIncludeDirs[j];
if (file.StartsWith(dir))
{
header = file.Mid(dir.Len());
break;
}
}
if (header.IsEmpty())
{
if (pf->buildTargets != buildTargets)
continue;
wxFileName fn(file);
fn.MakeRelativeTo(curPath);
header = fn.GetFullPath();
}
header.Replace(_T("\\"), _T("/"), true);
files.insert(header);
}
}
}
}
// popup the auto completion window
if (!files.empty())
{
ed->GetControl()->ClearRegisteredImages();
ed->GetControl()->AutoCompSetIgnoreCase(false);
ed->GetControl()->AutoCompSetCancelAtStart(true);
ed->GetControl()->AutoCompSetFillUps(m_CCFillupChars);
ed->GetControl()->AutoCompSetChooseSingle(false);
ed->GetControl()->AutoCompSetAutoHide(true);
ed->GetControl()->AutoCompSetDropRestOfWord(m_IsAutoPopup ? false : true);
wxString final;
GetStringFromSet(final, files, _T(" "));
final.RemoveLast(); // remove last space
Manager::Get()->GetLogManager()->DebugLog(F(_T("Get include file count is %d, use time is %d"),
files.size(), sw.Time()));
ed->GetControl()->AutoCompShow(pos - lineStartPos - keyPos, final);
}
}
#include " --> worked very fast, but several includes missingAll code in here:
#include < --> still rather slow [and at the start I always have a lot of entries like this : /32/32/32/32/32/32/32....]
(...)
Almost all of the time is spent in the AutoCompShow call.
This is not a CC problem, but wxScintilla.
#include <cst|
#include <cstd
#include "
This problem does not occur in the Windows platform. :(Probably on windows you have far less header files. On linux many softwares install header files in /usr/include
More tests:Thanks a lot! :D
The problem is not the wxStringTokenizer, but appending the string to the listcontrol.
So limiting the maximal amount, or better kicking in the autocomp-listbox after 2 or more characters (as default, configurable) might be the best solution.
#include " --> worked very fast, but several includes missingFixed in r6708. :D
#include < --> still rather slow [and at the start I always have a lot of entries like this : /32/32/32/32/32/32/32....]
#include <
#include "
Next I added foo.h to the project, from that moment on the include list "foo.h" appears, but not bar.h [I even added the directory where main.cpp and foo/bar.h live as an include directory explicitly].#include "f // appear f****.h
do you say you also can reproduce this problem or that it works for you ?I can not reproduce you problem.
One thing up for debate. You say local files don't show up in the list unless they are part of the project. Agreed, but when that directory is however added as an include directory, they should appear.
So in my case I added the directory where main.cpp resides as include directory, but the local, not part of the project, bar.h : doesn't show up. I would think it should ?
wxArrayString& CodeCompletion::GetSystemIncludeDirs(Parser* parser, bool force)It seems can not have both! :(
{
static Parser* lastParser = NULL;
static wxArrayString incDirs;
if ((!parser || !force) && parser == lastParser)
return incDirs;
else
{
incDirs.Clear();
lastParser = parser;
}
cbProject* project = m_NativeParser.GetProjectByParser(parser);
wxString prjPath;
if (project)
prjPath = project->GetCommonTopLevelPath();
incDirs = parser->GetIncludeDirs();
for (size_t i = 0; i < incDirs.GetCount();)
{
if (incDirs.Last() != wxFILE_SEP_PATH)
incDirs.Append(wxFILE_SEP_PATH);
if (project && incDirs.StartsWith(prjPath))
incDirs.RemoveAt(i);
else
++i;
}
return incDirs;
}
if (project && incDirs[i].StartsWith(prjPath))
incDirs.RemoveAt(i);
CC not show std::towlowerhi,can you show the minimal sample code? also the steps to produce the bug.
note: CC show std::tolower
CC not show std::towlowerAre you kidding??? Does it show or not show std::tolower ???
note: CC show std::tolower
CC not show std::towlowerAre you kidding??? Does it show or not show std::tolower ???
note: CC show std::tolower
CC not show std::towlowerAre you kidding??? Does it show or not show std::tolower ???
note: CC show std::tolower
Notice the w in one of them, I think wide char version.
Right... my fault - I missed that. :oops:Notice the w in one of them, I think wide char version.Yes that's right to(W)lower (wide char) missing in the CodeCompletion list
/* The standard library needs the functions from the ISO C90 standard
in the std namespace. At the same time we want to be safe for
future changes and we include the ISO C99 code in the non-standard
namespace __c99. The C++ wrapper header take case of adding the
definitions to the global namespace. */
#pragma GCC system_header
#include <bits/c++config.h>
#if _GLIBCXX_HAVE_WCTYPE_H
#include <wctype.h>
#endif
#ifndef _GLIBCXX_CWCTYPE
#define _GLIBCXX_CWCTYPE 1
// Get rid of those macros defined in <wctype.h> in lieu of real functions.
#undef iswalnum
#undef iswalpha
#if _GLIBCXX_HAVE_ISWBLANK
# undef iswblank
#endif
#undef iswcntrl
#undef iswctype
#undef iswdigit
#undef iswgraph
#undef iswlower
#undef iswprint
#undef iswpunct
#undef iswspace
#undef iswupper
#undef iswxdigit
#undef towctrans
#undef towlower
#undef towupper
#undef wctrans
#undef wctype
#if _GLIBCXX_USE_WCHAR_T
_GLIBCXX_BEGIN_NAMESPACE(std)
using ::wctrans_t;
using ::wctype_t;
using ::wint_t;
using ::iswalnum;
using ::iswalpha;
#if _GLIBCXX_HAVE_ISWBLANK
using ::iswblank;
#endif
using ::iswcntrl;
using ::iswctype;
using ::iswdigit;
using ::iswgraph;
using ::iswlower;
using ::iswprint;
using ::iswpunct;
using ::iswspace;
using ::iswupper;
using ::iswxdigit;
using ::towctrans;
using ::towlower;
using ::towupper;
using ::wctrans;
using ::wctype;
_GLIBCXX_END_NAMESPACE
#endif //_GLIBCXX_USE_WCHAR_T
void test() {}
namespace qp
{
using ::test;
}
int main()
{
qp::test();
return 0;
}
I have towlower.
It's not in std-namespace, but in global namespace.
So I think it is correctly found in global namespace, and it can (and should ? ) be used without std:: ( at least here it works fine).