The 12 september 2010 build (6583) CODECOMPLETION BRANCH version is out.

[ollydbg]

I have another issue here (using 6583 build, Vista OS, SP2)... btw, I really love the new features... you guys rule !!!

My problem is that when I use the new "Find functions called by ..." or "Find functions calling ..." in the context menu, I have the following error on the status bar of Cscope:

"Error while calling cscope occured!"

What am I missing here???

Thx,

This feature "Find functions called by ..." or "Find functions calling ..." is not supplied by CodeCompletion plugin. They are supplied by cscope plugin. Did you have cscope.exe in your PATH?

[Jenna]

I have another issue here (using 6583 build, Vista OS, SP2)... btw, I really love the new features... you guys rule !!!

My problem is that when I use the new "Find functions called by ..." or "Find functions calling ..." in the context menu, I have the following error on the status bar of Cscope:

"Error while calling cscope occured!"

What am I missing here???

Thx,

The cscope executable in your path.
It has to be downloaded seperately from there project page: http://cscope.sourceforge.net/

[daniloz]

Ok, thank you jens and ollydbg for the info... I am downloading cscope right now... ;-)

[killerbot]

I have a strange issue. I have a very little test example using boost::variant.
[on linux]

That means main.cpp does :

Code

#include <boost/variant.hpp>

I right click on it to open that header. ==> Not found : boost/variant.hpp
Right click again and choose to open it --> now it succeeds.

I noticed it also happened with regular std header files.

Anyone else suffering from this ??

[ollydbg]

The call tip is still a bit weird:

Notice the cursor before the 1.
I'd expect it to highlight the parameter at the cursor, not the last one.

I guess this problem is that
caret position will locate the actual parameter list
then semicolon information is used to show tooltip, so caret info should be used here either. I will look into it.

[ollydbg]

It seems to be related to the mingw-w64 tool chain.  If I set the compiler to the 'mingw.org' tool chain, everything works as expected.  Is there a way to check to see what the parser doesn't like about the mingw-w64 headers?

Incidentally, there seems to be a bug in that the default compiler headers are parsed irregardless of what the compiler is set to in the project.

The simple logic when CC get all the compiler headers directory is:
1. CC will run a dummy preprocessor command "cpp -v -E -x c++ nul"
2. Then CC will read the output of this command and parse (If I remember correct, it use regex match) this file and correct all the directories as it's search path.

To your problem, it seems: the directories were not correctly parsed by CC, so you need to add them manually.
I don't have a Win64 system, But I think it is easy to fix.

[Loaden]

Improve V2:
Change Log
1. Make system header files code-completion configurable
2. Enhance performance by CC member variables
3. Fixed switch parser error
4. Add some debug log

[Loaden]

It seems to be related to the mingw-w64 tool chain.  If I set the compiler to the 'mingw.org' tool chain, everything works as expected.  Is there a way to check to see what the parser doesn't like about the mingw-w64 headers?

Incidentally, there seems to be a bug in that the default compiler headers are parsed irregardless of what the compiler is set to in the project.

The simple logic when CC get all the compiler headers directory is:
1. CC will run a dummy preprocessor command "cpp -v -E -x c++ nul"
2. Then CC will read the output of this command and parse (If I remember correct, it use regex match) this file and correct all the directories as it's search path.

To your problem, it seems: the directories were not correctly parsed by CC, so you need to add them manually.
I don't have a Win64 system, But I think it is easy to fix.

I don't have a x64 system too.
So, I need you debug log, see post in here.
http://forums.codeblocks.org/index.php/topic,13291.msg89450.html#msg89450

[Loaden]

I have a strange issue. I have a very little test example using boost::variant.
[on linux]

That means main.cpp does :

Code

#include <boost/variant.hpp>

I right click on it to open that header. ==> Not found : boost/variant.hpp
Right click again and choose to open it --> now it succeeds.

I noticed it also happened with regular std header files.

Anyone else suffering from this ??

I think it will be fixing in this post.
http://forums.codeblocks.org/index.php/topic,13291.msg89512.html#msg89512

[ironhead]

It seems to be related to the mingw-w64 tool chain.  If I set the compiler to the 'mingw.org' tool chain, everything works as expected.  Is there a way to check to see what the parser doesn't like about the mingw-w64 headers?

Incidentally, there seems to be a bug in that the default compiler headers are parsed irregardless of what the compiler is set to in the project.

The simple logic when CC get all the compiler headers directory is:
1. CC will run a dummy preprocessor command "cpp -v -E -x c++ nul"
2. Then CC will read the output of this command and parse (If I remember correct, it use regex match) this file and correct all the directories as it's search path.

To your problem, it seems: the directories were not correctly parsed by CC, so you need to add them manually.
I don't have a Win64 system, But I think it is easy to fix.

I don't have a x64 system too.
So, I need you debug log, see post in here.
http://forums.codeblocks.org/index.php/topic,13291.msg89450.html#msg89450

I've been away from home for the past couple of days (and away from my x64 machine).  I'll be home tonight and I'll run the build you provided and send you the logs.

[Loaden]

I've been away from home for the past couple of days (and away from my x64 machine).  I'll be home tonight and I'll run the build you provided and send you the logs.

Okay, thanks!

[ironhead]

I've been away from home for the past couple of days (and away from my x64 machine).  I'll be home tonight and I'll run the build you provided and send you the logs.

Okay, thanks!

This is really odd, using the test build you supplied, CC worked as expected with 'std::'.  Perhaps it has something to do with my configuration then, since as I understand it the test build you supplied is self-contained.

I've attached the log files for your reference anyway.

Thank you!

[Loaden]

Update: I can't reproduce any more.
I reproduce only once, here is the crash report.

And, I can't find the reason, any comment?

I tried a couple more times and managed to reproduce again. Remember, a crash only happens if the line number margin changes from fixed to dynamic, while at least one file remains changed and not saved.
For both of our cases, the RPT file seems to trace the issue back to cbPlugin::CanDetach(), but I don't know how this works well enough.
How does CodeCompletion read the editor settings? There could be a dangling pointer that causes the error when the settings are updated.

Could you trying this build too?
Thanks!
http://portablecb.googlecode.com/files/CB_CCBRANCH_6581.7z

I just tried the build you supplied, and with this version, the margin is updated, but C::B hangs. Not even the logs are written.

My OS is Vista, SP2.

The issue should be fixed by this patch.
Please have a try:http://portablecb.googlecode.com/files/CB_CCBRANCH_5896_patched.7z

[Loaden]

I've been away from home for the past couple of days (and away from my x64 machine).  I'll be home tonight and I'll run the build you provided and send you the logs.

Okay, thanks!

This is really odd, using the test build you supplied, CC worked as expected with 'std::'.  Perhaps it has something to do with my configuration then, since as I understand it the test build you supplied is self-contained.

I've attached the log files for your reference anyway.

Thank you!

Caching GCC dir: C:\MinGW64\include\c++\4.5.2
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../include/c++/4.5.2/x86_64-w64-mingw32
Caching GCC dir: C:\MinGW64\include\c++\4.5.2\x86_64-w64-mingw32
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../include/c++/4.5.2/backward
Caching GCC dir: C:\MinGW64\include\c++\4.5.2\backward
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.2/include
Caching GCC dir: C:\MinGW64\lib\gcc\x86_64-w64-mingw32\4.5.2\include
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.2/include-fixed
Caching GCC dir: C:\MinGW64\lib\gcc\x86_64-w64-mingw32\4.5.2\include-fixed
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/include
Caching GCC dir: C:\MinGW64\x86_64-w64-mingw32\include

Yeah, It should be works well, just some compiler configure error.

[killerbot]

I have a strange issue. I have a very little test example using boost::variant.
[on linux]

That means main.cpp does :

Code

#include <boost/variant.hpp>

I right click on it to open that header. ==> Not found : boost/variant.hpp
Right click again and choose to open it --> now it succeeds.

I noticed it also happened with regular std header files.

Anyone else suffering from this ??

confirmed fixed.