Author Topic: The 12 september 2010 build (6583) CODECOMPLETION BRANCH version is out. (Read 70891 times)

killerbot · « **on:** September 12, 2010, 04:39:04 pm »

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2810_gcc441.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc441.7z

The 12 September 2010 build is out.
- Windows :
http://prdownload.berlios.de/codeblocks/CB_20100912_rev6583_CC_BRANCH_win32.7z
- Linux :
none

Important changes compared to regular nightly:

01. Parser now support conditional preprocessor expression handling.
02. Support Parsing stand alone files without any CB project opened. Now, CB can be regard as a code browser. both symbols tree and codecompletin can still be used.
03. Add CC toolbar scope selection, improve toolbar state synchronization with the editor.
04. Partially added the re-factoring function, rename symbol, find reference
05. Automatically add the opening and closing brace ({ }) and semicolons after "class" or "enum" keyword.
06. Support smart tab jump, this behavior is like Eclipse editing style.
07. Added support for showing Call tip when typing Macros
08. Added support "step in" and "step out" for cdb debugger
09. Smart auto-compleiton: Avoid adding extra duplicate text if some similar text is behind the caret.
10. Add "Stream Comment", just use "Edit > Stream Comment" menu item.
11. AStyle now support format on selected text
12. One parser per project, this means several parser objects and tokenstrees can coexist in the same workspace.
13. Context menu supporting "reparse select project" and "reparse select file"
14. partially add template parsing, improve call tip( show the formal template argument together)
15. Class browser now support muti-directory swaping and jumping of source files, so the tokens information show in the symbols tree were merged and shown correctly.
16. Supporting auto-completion for header files and system files.
17. Added operator overloading for template class, support smart-pointer for * [] -> overloading.
18. Support auto indent for "if/else/for/while/do"
19. Parsing now can do macro expension, so that a lot of macro mixed code (like wxWidgets' code) can parse correctly.
20. Jump to function declaration or function implementation is much precise.
21. Refactor the CC's AI match algorithm( remove the recusive code), improve performance, and avoid some hang situation.
22. Auto cancel indent when type 'public:' or 'protected:' or 'private:'
23. Add feature for wxSmith's identifier handler (http://forums.codeblocks.org/index.php/topic,12345.0.html)
24. Parser now record the correct line information of Token
25. Update sash position correctly
26. Fix dropping files with wx 2.8.11
27. Add support for MSVC 10
28. Fix CompilerInheritsFrom msvc8 error
29. Support handle "using namespace" and its hierarchy
30. Improve adding parentheses after function name (auto completion)
31. Aupport saving the token list of files in debug info
32. Remove duplicate "basic_string"
33. Refactor the DoParse function in ParserThread, change from if/else to switch/case (improve performance)
34. Use hash-map to do the Macro replacement text search, (improve performance)
35. Fix bugs when delete a token, all its child token was deleted, this will cause empty toolbar problem
36. Change the short-key to do the codecompletion from Ctrl+SPACE to Shift+SPACE only for Chinese,Japanese or Korean system, because in Chinese,Japanese or Korean System, Ctrl+SPACE is always used to switch IME.
37. Improve code-completion when use global namespace.
38. Dynamically class hierarchy calculation.
39. Add up-front headers support, improve batch parsing.
40. Extra parser thread Parser logic fix and improvement.

THIS IS A SPECIAL TEST BUILD OF REFACTORINGS CARRIED OUT ON THE CODE COMPLETION BRANCH IN OUR SVN.
FOCUS IS ON ENHANCED CODE COMPLETION USABILITY.

Give your feedback on this version only in this thread, don't mix it with the regular nightly please.

Once we don't have any blockers on this version,we will merge the changes into trunk and it will be part of the regular nightlies.

Loaden · « **Reply #1 on:** September 13, 2010, 12:35:22 am »

NOTICE: Please set the compiler's installation directory first, then CC will works well.

The second change log, thanks a14331990 help me translate.

01. Parser now support conditional preprocessor directives.
02. Support Parsing stand alone files without any CB project opened. Now, CB can be regard as a code browser. both symbols tree and codecompletin can still be used.
03. Add CC toolbar scope selection, improve toolbar state synchronization with the editor.
04. Partially added the re-factoring function, rename symbol, find reference
05. Automatically add the opening and closing brace ({ }) and semicolons after "class" or "enum" keyword.
06. Support smart tab jump, this behavior is like Eclipse editing style.
07. Added support for showing Call tip when typing Macros
08. Added support "step in" and "step out" for cdb debugger
09. Smart auto-compleiton: Avoid adding extra duplicate text if some similar text is behind the caret.
10. Add "Stream Comment", just use "Edit > Stream Comment" menu item.
11. AStyle now support format on selected text
12. One parser per project, this means several parser objects and tokenstrees can coexist in the same workspace.
13. Context menu supporting "reparse select project" and "reparse select file"
14. partially add template parsing, improve call tip( show the formal template argument together)
15. Class browser now support muti-directory swaping and jumping of source files, so the tokens information show in the symbols tree were merged and shown correctly.
16. Supporting auto-completion for header files and system files.
17. Added operator overloading for template class, support smart-pointer for * [] -> overloading.
18. Support auto indent for "if/else/for/while/do"
19. Parsing now can do macro expension, so that a lot of macro mixed code (like wxWidgets' code) can parse correctly.
20. Jump to function declaration or function implementation is much precise.
21. Refactor the CC's AI match algorithm( remove the recusive code), improve performance, and avoid some hang situation.
22. Auto cancel indent when type 'public:' or 'protected:' or 'private:'
23. Add feature for wxSmith's identifier handler (http://forums.codeblocks.org/index.php/topic,12345.0.html)
24. Parser now record the correct line information of Token
25. Update sash position correctly
26. Fix dropping files with wx 2.8.11
27. Add support for MSVC 10
28. Fix CompilerInheritsFrom msvc8 error
29. Support handle "using namespace" and its hierarchy
30. Improve adding parentheses after function name (auto completion)
31. Aupport saving the token list of files in debug info
32. Remove duplicate "basic_string"
33. Refactor the DoParse function in ParserThread, change from if/else to switch/case (improve performance)
34. Use hash-map to do the Macro replacement text search, (improve performance)
35. Fix bugs when delete a token, all its child token was deleted, this will cause empty toolbar problem
36. Change the short-key to do the codecompletion from Ctrl+SPACE to Shift+SPACE only for Chinese,Japanese or Korean system, because in Chinese,Japanese or Korean System, Ctrl+SPACE is always used to switch IME.
37. Improve code-completion when use global namespace.
38. Dynamically class hierarchy calculation.
39. Add up-front headers support, improve batch parsing.
40. Extra parser thread Parser logic fix and improvement.

ironhead · « **Reply #2 on:** September 13, 2010, 03:48:11 am »

I'm not sure if it's just me, but with this build, I std namespace completion doesn't seem to work. For example:

Code

std::

Under the normal nightly will list the std classes, with this release, I don't get that behaviour.

Loaden · « **Reply #3 on:** September 13, 2010, 04:13:48 am »

Quote from: ironhead on September 13, 2010, 03:48:11 am

I'm not sure if it's just me, but with this build, I std namespace completion doesn't seem to work. For example:

Code
std::
Under the normal nightly will list the std classes, with this release, I don't get that behaviour.

Could you show some test code?
Works well in here.

Code

#include <iostream>

class A
{
public:
    void Test();
};

int main()
{
    std::
    return 0;
}

ollydbg · « **Reply #4 on:** September 13, 2010, 09:24:48 am »

Quote from: ironhead on September 13, 2010, 03:48:11 am

I'm not sure if it's just me, but with this build, I std namespace completion doesn't seem to work. For example:

Code
std::
Under the normal nightly will list the std classes, with this release, I don't get that behaviour.

iron, as Loaden said, what's the exact problem you meet? it works fine in my winXP system.

Loaden · « **Reply #5 on:** September 13, 2010, 09:26:06 am »

Quote from: ironhead on September 13, 2010, 03:48:11 am

I'm not sure if it's just me, but with this build, I std namespace completion doesn't seem to work. For example:

Code
std::
Under the normal nightly will list the std classes, with this release, I don't get that behaviour.

Hi, I got it.
Please set the compiler's installation directory first, then CC will works well.

danteri · « **Reply #6 on:** September 13, 2010, 10:52:43 am »

hi

this branch is great
my project used to hang around 2 minutes on startup on regular cb nightly
now it is starting instantly

thank you for great work on this branch and fast merge with trunk
see no regressions so far

Loaden · « **Reply #7 on:** September 13, 2010, 11:02:03 am »

Quote from: danteri on September 13, 2010, 10:52:43 am

my project used to hang around 2 minutes on startup on regular cb nightly
now it is starting instantly

I'm do not Understand, could you get me more explain?

ptDev · « **Reply #8 on:** September 13, 2010, 11:15:08 am »

Found a subtle bug, related to refreshing of a changed editor window. It may lead to a crash.
I'm not sure if it also affects the main branch nightly, but I can confirm it impacts the CC branch.

To reproduce:
*Create or open any project, a "Hello World" will do.
*Edit any source file (e.g., main.cpp), and do not save the file.
*Go to Settings > Editor > Margins and caret.
*Change the "left margin" "width for line numbers" from the fixed value to dynamic by checking the checkbox.
*Press "OK" to confirm changes.
*Code::Blocks will fail to update the Scintilla window if the line number width changes from fixed to dynamic. If there are any edited and unsaved files, C::B crashes.

No crash occurs if all the files are saved or if we change the line margin from dynamic to fixed.

UPDATE:
FYI, The output in codeblocks.RPT.

Quote

Error occured on Monday, September 13, 2010 at 10:56:21.

D:\CCCB\codeblocks.exe caused an Access Violation at location 65f27cee in module D:\CCCB\share\codeblocks\plugins\codecompletion.dll Reading from location ffffff10.

Registers:
eax=ffffff10 ebx=0518ba7f ecx=0524256c edx=0518ba7b esi=00000000 edi=00000000
eip=65f27cee esp=07d9f448 ebp=07d9f448 iopl=0 nv up ei ng nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010282

Call stack:
65F27CEE D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65F27CEE _ZNK8cbPlugin9CanDetachEv
65F519E9 D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65F519E9 _ZNK8cbPlugin9CanDetachEv
65F518C5 D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65F518C5 _ZNK8cbPlugin9CanDetachEv
65F38B9C D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65F38B9C _ZNK8cbPlugin9CanDetachEv
65F38C6D D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65F38C6D _ZNK8cbPlugin9CanDetachEv
65F010F2 D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65F010F2
65F01B1A D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65F01B1A
65F17BD8 D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65F17BD8
65EED681 D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65EED681
65EEDD71 D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65EEDD71
65EF5A24 D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65EF5A24
65EF24A6 D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65EF24A6
65EF1DC4 D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65EF1DC4
65EEBE04 D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65EEBE04
65EEB864 D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65EEB864
65F1B8F5 D:\CCCB\share\codeblocks\plugins\codecompletion.dll:65F1B8F5 _ZN12cbToolPlugin9BuildMenuEP9wxMenuBar
617F7F54 D:\CCCB\codeblocks.dll:617F7F54 _ZN12cbThreadPool14cbWorkerThread5EntryEv
6CCD6954 D:\CCCB\wxmsw28u_gcc_cb.dll:6CCD6954 _ZN11wxConditionD2Ev
6CCD6AD8 D:\CCCB\wxmsw28u_gcc_cb.dll:6CCD6AD8 _ZN11wxConditionD2Ev
75862599 C:\Windows\system32\msvcrt.dll:75862599 wcstombs
758626B3 C:\Windows\system32\msvcrt.dll:758626B3 _beginthreadex
76E6D0E9 C:\Windows\system32\kernel32.dll:76E6D0E9 BaseThreadInitThunk
770119BB C:\Windows\system32\ntdll.dll:770119BB RtlInitializeExceptionChain
7701198E C:\Windows\system32\ntdll.dll:7701198E RtlInitializeExceptionChain

ptDev · « **Reply #9 on:** September 13, 2010, 11:16:41 am »

Oh, and regarding the CodeCompletion itself. I'm very happy with these changes, it is noticeably faster and more user-friendly now. I vote for a merge

Loaden · « **Reply #10 on:** September 13, 2010, 11:41:00 am »

Quote from: ptDev on September 13, 2010, 11:15:08 am

Found a subtle bug, related to refreshing of a changed editor window. It may lead to a crash.
I'm not sure if it also affects the main branch nightly, but I can confirm it impacts the CC branch.

To reproduce:
*Create or open any project, a "Hello World" will do.
*Edit any source file (e.g., main.cpp), and do not save the file.
*Go to Settings > Editor > Margins and caret.
*Change the "left margin" "width for line numbers" from the fixed value to dynamic by checking the checkbox.
*Press "OK" to confirm changes.
*Code::Blocks will fail to update the Scintilla window if the line number width changes from fixed to dynamic. If there are any edited and unsaved files, C::B crashes.

No crash occurs if all the files are saved or if we change the line margin from dynamic to fixed.

Confirmed!

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

Quote

-------------------

Error occured on Monday, September 13, 2010 at 17:35:24.

D:\DengYC\CCBRANCH\codeblocks.exe caused an Access Violation at location 77c172e3 in module C:\WINDOWS\system32\msvcrt.dll Reading from location 07617000.

Registers:
eax=04444b54 ebx=04444b54 ecx=3f38b6d5 edx=00000000 esi=07617000 edi=0447b01c
eip=77c172e3 esp=0022f408 ebp=0022f410 iopl=0 nv up ei pl nz ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010212

Call stack:
77C172E3 C:\WINDOWS\system32\msvcrt.dll:77C172E3 memmove
65F31F22 D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F31F22 _ZNK8cbPlugin9CanDetachEv
65F530FB D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F530FB _ZNK8cbPlugin9CanDetachEv
65F53D19 D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F53D19 _ZNK8cbPlugin9CanDetachEv
65F5660A D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F5660A _ZNK8cbPlugin9CanDetachEv
65F369D7 D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F369D7 _ZNK8cbPlugin9CanDetachEv
65F54A7B D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F54A7B _ZNK8cbPlugin9CanDetachEv
65F5555B D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F5555B _ZNK8cbPlugin9CanDetachEv
65F5599A D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F5599A _ZNK8cbPlugin9CanDetachEv
65F43734 D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F43734 _ZNK8cbPlugin9CanDetachEv
65F4397C D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F4397C _ZNK8cbPlugin9CanDetachEv
65F0109B D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F0109B
65F01B1A D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F01B1A
65F08D91 D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F08D91
65F08DE6 D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65F08DE6
65EEF1A2 D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65EEF1A2
65ECF497 D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65ECF497
65EE203F D:\DengYC\CCBRANCH\share\codeblocks\plugins\codecompletion.dll:65EE203F
6CCDC431 D:\DengYC\CCBRANCH\wxmsw28u_gcc_cb.dll:6CCDC431 _ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent
6CCDDD6B D:\DengYC\CCBRANCH\wxmsw28u_gcc_cb.dll:6CCDDD6B _ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler
6CCDDE3C D:\DengYC\CCBRANCH\wxmsw28u_gcc_cb.dll:6CCDDE3C _ZN12wxEvtHandler12ProcessEventER7wxEvent
6CCDD773 D:\DengYC\CCBRANCH\wxmsw28u_gcc_cb.dll:6CCDD773 _ZN12wxEvtHandler20ProcessPendingEventsEv
6CC41518 D:\DengYC\CCBRANCH\wxmsw28u_gcc_cb.dll:6CC41518 _ZN12wxAppConsole20ProcessPendingEventsEv
6D1171B1 D:\DengYC\CCBRANCH\wxmsw28u_gcc_cb.dll:6D1171B1 _ZN18wxHtmlSearchEngineD1Ev
77D2B372 C:\WINDOWS\system32\USER32.dll:77D2B372 MoveWindow
77D2B317 C:\WINDOWS\system32\USER32.dll:77D2B317 MoveWindow
77D278D0 C:\WINDOWS\system32\USER32.dll:77D278D0 GetWindowTextLengthW
7C92E473 C:\WINDOWS\system32\ntdll.dll:7C92E473 KiUserCallbackDispatcher
6CD1B92A D:\DengYC\CCBRANCH\wxmsw28u_gcc_cb.dll:6CD1B92A _ZN11wxEventLoop8DispatchEv
6CDD4B27 D:\DengYC\CCBRANCH\wxmsw28u_gcc_cb.dll:6CDD4B27 _ZN17wxEventLoopManual3RunEv
6CDABF29

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

danteri · « **Reply #11 on:** September 13, 2010, 01:06:47 pm »

Quote from: Loaden on September 13, 2010, 11:02:03 am

Quote from: danteri on September 13, 2010, 10:52:43 am
my project used to hang around 2 minutes on startup on regular cb nightly
now it is starting instantly
I'm do not Understand, could you get me more explain?

hi Loaden

i was mean this scenario:
- run cb
- load project file
- wait around 2 minutes until cb finish thinking (this 2 minutes cb would not respond, just hang window until it finish thinking)
- start interactive working

now with cc branch cb no longer needs 2 minutes to think after load project files
it gives interactive prompt almost instantly

it was very annoying in old cb

thank you for all work on this
very appreciated

ptDev · « **Reply #12 on:** September 13, 2010, 01:36:59 pm »

Quote from: Loaden on September 13, 2010, 11:41:00 am

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.

ironhead · « **Reply #13 on:** September 13, 2010, 03:18:58 pm »

Quote from: Loaden on September 13, 2010, 09:26:06 am

Quote from: ironhead on September 13, 2010, 03:48:11 am
I'm not sure if it's just me, but with this build, I std namespace completion doesn't seem to work. For example:

Code
std::
Under the normal nightly will list the std classes, with this release, I don't get that behaviour.
Hi, I got it.
Please set the compiler's installation directory first, then CC will works well.

I'm using the drangon MinGW64-w64 native 64 bit compiler and I have my tool chain directory set properly (C:\MinGW64) and I've even added the included directories specifically (C:\MinGW\include, C:\MinGW63\x64_64-w64-mingw32\include) to the compiler search directories. The w32api functions (i.e. CreateWindow, etc.) work fine, but the std namespace classes do not. I've tested with your example code and I get no listing after std::, however, if I type A:: I see Test() listed.

Is there some sort of log window or something for CC that I can bring up to see what's happening?

Loaden · « **Reply #14 on:** September 13, 2010, 04:06:50 pm »

Quote from: ironhead on September 13, 2010, 03:18:58 pm

Is there some sort of log window or something for CC that I can bring up to see what's happening?

Could you execute this in cmd, and show what is the output?

Code

cpp -v -E -x c++ nul

In here, the output content is:

Quote

loaden@qpsoft codecompletion]$ cpp -v -E -x c++ /dev/null
Using built-in specs.
COLLECT_GCC=cpp
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-gnu-unique-object --enable-lto --enable-plugin --disable-multilib --disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
Thread model: posix
gcc version 4.5.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=pentiumpro'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/cc1plus -E -quiet -v -D_GNU_SOURCE /dev/null -mtune=generic -march=pentiumpro
ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../../include/c++/4.5.1
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../../include/c++/4.5.1/i686-pc-linux-gnu
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../../include/c++/4.5.1/backward
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/include
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/include-fixed
/usr/include
End of search list.
# 1 "/dev/null"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/dev/null"
COMPILER_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/:/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/:/usr/lib/gcc/i686-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/:/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=pentiumpro'

Loaden · « **Reply #15 on:** September 13, 2010, 04:12:28 pm »

By the way, could you launch CB with "codeblocks.exe --debug-log", and put the debug log in here?
Thanks!

blueshake · « **Reply #16 on:** September 13, 2010, 04:13:06 pm »

1.add the arguments "--debug-log" to the shortcut for codeblock.
2.press ctrl and shift ,right click the symbol tree, click debug smartsense.
3.type std::
4.post the output log here,please.

ironhead · « **Reply #17 on:** September 13, 2010, 04:40:20 pm »

Here's what I see in the debug log:

Code

Create new parser for project '*NONE*'
Starting batch parsing for project '*NONE*'...
Project '*NONE*' parsing stage done!
Project '*NONE*' parsing stage done (1 total parsed files, 3 tokens in 0 minute(s), 0.000 seconds).
Updating class browser...
Class browser updated.
MarkItemsByAI()
ParseUsingNamespace() Parse file scope for "using namespace"
ParseFunctionArguments() Parse function arguments
FindCurrentFunctionStart() Looking for tokens in 'C:\Users\Chris\Documents\test.cpp'
FindCurrentFunctionStart() Found 3 results
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='class A {...}', tF='C:\Users\Chris\Documents\test.cpp', tStart=4, tEnd=7
FindCurrentFunctionStart() Function out of bounds: tN='class A {...}', tF='C:\Users\Chris\Documents\test.cpp', tStart=4, tEnd=7, line=11 (size_t)line=11
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='void A::Test()', tF='C:\Users\Chris\Documents\test.cpp', tStart=0, tEnd=0
FindCurrentFunctionStart() Function out of bounds: tN='void A::Test()', tF='C:\Users\Chris\Documents\test.cpp', tStart=0, tEnd=0, line=11 (size_t)line=11
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int main()', tF='C:\Users\Chris\Documents\test.cpp', tStart=10, tEnd=13
FindCurrentFunctionStart() Current function: 'int main()' (at line 9)
FindCurrentFunctionStart() Namespace='', proc='main' (returning 80)
GenerateResultSet() search 'main', parent='Global namespace (id:0, type:(null)), isPrefix=0'
ParseFunctionArguments() + Function match: main
ParseLocalBlock() Parse local block
FindCurrentFunctionStart() Looking for tokens in 'C:\Users\Chris\Documents\test.cpp'
FindCurrentFunctionStart() Found 3 results
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='class A {...}', tF='C:\Users\Chris\Documents\test.cpp', tStart=4, tEnd=7
FindCurrentFunctionStart() Function out of bounds: tN='class A {...}', tF='C:\Users\Chris\Documents\test.cpp', tStart=4, tEnd=7, line=11 (size_t)line=11
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='void A::Test()', tF='C:\Users\Chris\Documents\test.cpp', tStart=0, tEnd=0
FindCurrentFunctionStart() Function out of bounds: tN='void A::Test()', tF='C:\Users\Chris\Documents\test.cpp', tStart=0, tEnd=0, line=11 (size_t)line=11
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int main()', tF='C:\Users\Chris\Documents\test.cpp', tStart=10, tEnd=13
FindCurrentFunctionStart() Current function: 'int main()' (at line 9)
FindCurrentFunctionStart() Namespace='', proc='main' (returning 80)
ParseLocalBlock() Block:

    std::
ParseLocalBlock() Local tokens:
AI() =========================================================
AI() Doing AI for '    std::':
FindCurrentFunctionStart() Looking for tokens in 'C:\Users\Chris\Documents\test.cpp'
FindCurrentFunctionStart() Found 3 results
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='class A {...}', tF='C:\Users\Chris\Documents\test.cpp', tStart=4, tEnd=7
FindCurrentFunctionStart() Function out of bounds: tN='class A {...}', tF='C:\Users\Chris\Documents\test.cpp', tStart=4, tEnd=7, line=11 (size_t)line=11
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='void A::Test()', tF='C:\Users\Chris\Documents\test.cpp', tStart=0, tEnd=0
FindCurrentFunctionStart() Function out of bounds: tN='void A::Test()', tF='C:\Users\Chris\Documents\test.cpp', tStart=0, tEnd=0, line=11 (size_t)line=11
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int main()', tF='C:\Users\Chris\Documents\test.cpp', tStart=10, tEnd=13
FindCurrentFunctionStart() Current function: 'int main()' (at line 9)
FindCurrentFunctionStart() Namespace='', proc='main' (returning 80)
GenerateResultSet() search 'main', parent='Global namespace (id:0, type:(null)), isPrefix=0'
AI() Adding search namespace: Global namespace
BreakUpComponents() Breaking up '    std::'
BreakUpComponents() Found component: 'std' (Namespace)
BreakUpComponents() Adding component: 'std'.
BreakUpComponents() Found component: '' (SearchText)
BreakUpComponents() Adding component: ''.
ResolveExpression() search scope is 1 result.
search scope: -1
ResolveExpression() Looping 0 result.
AI() AI leave, returned 0 results
0 results
Reparsing when typing for editor C:\Users\Chris\Documents\test.cpp
Reparsing modified files for project '*NONE*'
Project '*NONE*' parsing stage done (1 total parsed files, 3 tokens in 0 minute(s), 0.000 seconds).
Updating class browser...
Class browser updated.
MarkItemsByAI()
ParseUsingNamespace() Parse file scope for "using namespace"
ParseFunctionArguments() Parse function arguments
FindCurrentFunctionStart() Looking for tokens in 'C:\Users\Chris\Documents\test.cpp'
FindCurrentFunctionStart() Found 3 results
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='void A::Test()', tF='C:\Users\Chris\Documents\test.cpp', tStart=0, tEnd=0
FindCurrentFunctionStart() Function out of bounds: tN='void A::Test()', tF='C:\Users\Chris\Documents\test.cpp', tStart=0, tEnd=0, line=11 (size_t)line=11
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int main()', tF='C:\Users\Chris\Documents\test.cpp', tStart=10, tEnd=13
FindCurrentFunctionStart() Current function: 'int main()' (at line 9)
FindCurrentFunctionStart() Namespace='', proc='main' (returning 80)
GenerateResultSet() search 'main', parent='Global namespace (id:0, type:(null)), isPrefix=0'
ParseFunctionArguments() + Function match: main
ParseLocalBlock() Parse local block
FindCurrentFunctionStart() Looking for tokens in 'C:\Users\Chris\Documents\test.cpp'
FindCurrentFunctionStart() Found 3 results
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='void A::Test()', tF='C:\Users\Chris\Documents\test.cpp', tStart=0, tEnd=0
FindCurrentFunctionStart() Function out of bounds: tN='void A::Test()', tF='C:\Users\Chris\Documents\test.cpp', tStart=0, tEnd=0, line=11 (size_t)line=11
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int main()', tF='C:\Users\Chris\Documents\test.cpp', tStart=10, tEnd=13
FindCurrentFunctionStart() Current function: 'int main()' (at line 9)
FindCurrentFunctionStart() Namespace='', proc='main' (returning 80)
ParseLocalBlock() Block:

    std::
ParseLocalBlock() Local tokens:
AI() =========================================================
AI() Doing AI for '    std::':
FindCurrentFunctionStart() Looking for tokens in 'C:\Users\Chris\Documents\test.cpp'
FindCurrentFunctionStart() Found 3 results
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='void A::Test()', tF='C:\Users\Chris\Documents\test.cpp', tStart=0, tEnd=0
FindCurrentFunctionStart() Function out of bounds: tN='void A::Test()', tF='C:\Users\Chris\Documents\test.cpp', tStart=0, tEnd=0, line=11 (size_t)line=11
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int main()', tF='C:\Users\Chris\Documents\test.cpp', tStart=10, tEnd=13
FindCurrentFunctionStart() Current function: 'int main()' (at line 9)
FindCurrentFunctionStart() Namespace='', proc='main' (returning 80)
GenerateResultSet() search 'main', parent='Global namespace (id:0, type:(null)), isPrefix=0'
AI() Adding search namespace: Global namespace
BreakUpComponents() Breaking up '    std::'
BreakUpComponents() Found component: 'std' (Namespace)
BreakUpComponents() Adding component: 'std'.
BreakUpComponents() Found component: '' (SearchText)
BreakUpComponents() Adding component: ''.
ResolveExpression() search scope is 1 result.
search scope: -1
ResolveExpression() Looping 0 result.
AI() AI leave, returned 0 results
0 results

The output of the cpp command gives me:

Code

$ cpp -v -E -x c++ nul
Using built-in specs.
COLLECT_GCC=c:\MinGw64\bin\cpp.exe
COLLECT_LTO_WRAPPER=c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: /home/drangon/work/mingw-w64-dgn/source/gcc/configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++ --with-gmp=/home/drangon/work/mingw-w64-dgn/build/for_target --enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry --prefix=/home/drangon/work/mingw-w64-dgn/target --with-sysroot=/home/drangon/work/mingw-w64-dgn/target
Thread model: win32
gcc version 4.5.2 20100903 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=x86-64'
 c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.2/cc1plus.exe -E -quiet -v -iprefix c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.2/ nul -mtune=generic -march=x86-64
# 1 "nul"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "nul"
ignoring duplicate directory "c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../include/c++/4.5.2"
ignoring duplicate directory "c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../include/c++/4.5.2/x86_64-w64-mingw32"
ignoring duplicate directory "c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../include/c++/4.5.2/backward"
ignoring nonexistent directory "/home/drangon/work/mingw-w64-dgn/target/home/drangon/work/mingw-w64-dgn/target/lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../include"
ignoring duplicate directory "c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.2/include"
ignoring duplicate directory "c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.2/include-fixed"
ignoring duplicate directory "c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "/home/drangon/work/mingw-w64-dgn/target/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../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
 c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../include/c++/4.5.2/backward
 c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.5.2/include
 c:\mingw64\bin\../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
End of search list.
COMPILER_PATH=c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.2/;c:/mingw64/bin/../libexec/gcc/;c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/bin/
LIBRARY_PATH=c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/;c:/mingw64/bin/../lib/gcc/;c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../lib64/;c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/lib/;c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=x86-64'

Orgulas · « **Reply #18 on:** September 13, 2010, 08:28:18 pm »

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.

daniloz · « **Reply #19 on:** September 13, 2010, 08:54:55 pm »

I have the same issue with the most actual (normal) branch (should be equivalent to the normal nigthly build)... But had it since a long time now...

blueshake · « **Reply #20 on:** September 14, 2010, 01:17:31 am »

@ironhead
here is the issue.

can you check if the token "std" is in the tokentree??

Quote

ResolveExpression() search scope is 1 result.
search scope: -1
ResolveExpression() Looping 0 result.
AI() AI leave, returned 0 results
0 results

blueshake · « **Reply #21 on:** September 14, 2010, 01:19:39 am »

here is my log.

Quote

ResolveExpression() search scope is 2 result.
search scope: -1
search scope: 203
ResolveExpression() Looping 1 result.
ResolvExpression() Match:'std(ID=203) : type=''
ResolveExpression() search scope is 1 result.
search scope: 203
ResolveExpression() Looping 581 result.
ResolvExpression() Match:'cin(ID=423) : type='istream'
ResolvExpression() Match:'cout(ID=424) : type='ostream'
ResolvExpression() Match:'cerr(ID=425) : type='ostream'
ResolvExpression() Match:'clog(ID=426) : type='ostream'
ResolvExpression() Match:'wcin(ID=427) : type='wistream'
ResolvExpression() Match:'wcout(ID=428) : type='wostream'
ResolvExpression() Match:'wcerr(ID=429) : type='wostream'
ResolvExpression() Match:'wclog(ID=430) : type='wostream'
ResolvExpression() Match:'__ioinit(ID=431) : type='ios_base::Init'
ResolvExpression() Match:'basic_ostream(ID=433) : type=''
ResolvExpression() Match:'sentry(ID=472) : type=''
ResolvExpression() Match:'operator<<(ID=478) : type='basic_ostream'
ResolvExpression() Match:'operator<<(ID=479) : type='basic_ostream'
ResolvExpression() Match:'operator<<(ID=480) : type='basic_ostream'
ResolvExpression() Match:'operator<<(ID=481) : type='basic_ostream'
ResolvExpression() Match:'operator<<(ID=482) : type='basic_ostream'
ResolvExpression() Match:'operator<<(ID=483) : type='basic_ostream'
ResolvExpression() Match:'operator<<(ID=484) : type='basic_ostream'
ResolvExpression() Match:'operator<<(ID=485) : type='basic_ostream'
ResolvExpression() Match:'operator<<(ID=486) : type='basic_ostream'
ResolvExpression() Match:'operator<<(ID=487) : type='basic_ostream'
ResolvExpression() Match:'endl(ID=488) : type='basic_ostream'
ResolvExpression() Match:'ends(ID=489) : type='basic_ostream'
ResolvExpression() Match:'flush(ID=490) : type='basic_ostream'
ResolvExpression() Match:'basic_istream(ID=492) : type=''
ResolvExpression() Match:'operator>>(ID=558) : type='basic_istream'
ResolvExpression() Match:'operator>>(ID=559) : type='basic_istream'
ResolvExpression() Match:'operator>>(ID=560) : type='basic_istream'
ResolvExpression() Match:'operator>>(ID=561) : type='basic_istream'
ResolvExpression() Match:'operator>>(ID=562) : type='basic_istream'
ResolvExpression() Match:'operator>>(ID=563) : type='basic_istream'
ResolvExpression() Match:'operator>>(ID=564) : type='basic_istream'
ResolvExpression() Match:'basic_iostream(ID=565) : type=''
ResolvExpression() Match:'ws(ID=576) : type='basic_istream'
ResolvExpression() Match:'__ostream_write(ID=579) : type='void'
ResolvExpression() Match:'__ostream_fill(ID=580) : type='void'
ResolvExpression() Match:'__ostream_insert(ID=581) : type='basic_ostream'
ResolvExpression() Match:'__ostream_insert(ID=582) : type='&'
ResolvExpression() Match:'__ostream_insert(ID=583) : type='&'
ResolvExpression() Match:'sentry(ID=585) : type='basic_ostream::sentry::'
ResolvExpression() Match:'operator<<(ID=595) : type='basic_ostream'
ResolvExpression() Match:'endl(ID=596) : type='&'
ResolvExpression() Match:'ends(ID=597) : type='&'
ResolvExpression() Match:'flush(ID=598) : type='&'
ResolvExpression() Match:'operator<<(ID=599) : type='&'
ResolvExpression() Match:'operator<<(ID=600) : type='&'
ResolvExpression() Match:'operator<<(ID=601) : type='&'
ResolvExpression() Match:'operator<<(ID=602) : type='&'
ResolvExpression() Match:'operator<<(ID=603) : type='&'
ResolvExpression() Match:'operator<<(ID=604) : type='&'
ResolvExpression() Match:'ostream(ID=605) : type=''
ResolvExpression() Match:'endl(ID=612) : type='&'
ResolvExpression() Match:'ends(ID=613) : type='&'
ResolvExpression() Match:'flush(ID=614) : type='&'
ResolvExpression() Match:'operator<<(ID=615) : type='&'
ResolvExpression() Match:'operator<<(ID=616) : type='&'
ResolvExpression() Match:'operator<<(ID=617) : type='&'
ResolvExpression() Match:'operator<<(ID=618) : type='&'
ResolvExpression() Match:'wostream(ID=619) : type=''
ResolvExpression() Match:'sentry(ID=627) : type='basic_istream::sentry::'
ResolvExpression() Match:'operator>>(ID=648) : type='basic_istream'
ResolvExpression() Match:'ws(ID=649) : type='&'
ResolvExpression() Match:'operator>>(ID=650) : type='&'
ResolvExpression() Match:'operator>>(ID=651) : type='&'
ResolvExpression() Match:'operator>>(ID=652) : type='&'
ResolvExpression() Match:'operator>>(ID=653) : type='&'
ResolvExpression() Match:'operator>>(ID=654) : type='&'
ResolvExpression() Match:'operator>>(ID=655) : type='&'
ResolvExpression() Match:'istream(ID=656) : type=''
ResolvExpression() Match:'ws(ID=665) : type='&'
ResolvExpression() Match:'operator>>(ID=666) : type='&'
ResolvExpression() Match:'operator>>(ID=667) : type='&'
ResolvExpression() Match:'wistream(ID=668) : type=''
ResolvExpression() Match:'ios(ID=678) : type='basic_ios'
ResolvExpression() Match:'streambuf(ID=679) : type='basic_streambuf'
ResolvExpression() Match:'istream(ID=680) : type='basic_istream'
ResolvExpression() Match:'ostream(ID=681) : type='basic_ostream'
ResolvExpression() Match:'iostream(ID=682) : type='basic_iostream'
ResolvExpression() Match:'stringbuf(ID=683) : type='basic_stringbuf'
ResolvExpression() Match:'istringstream(ID=684) : type='basic_istringstream'
ResolvExpression() Match:'ostringstream(ID=685) : type='basic_ostringstream'
ResolvExpression() Match:'stringstream(ID=686) : type='basic_stringstream'
ResolvExpression() Match:'filebuf(ID=687) : type='basic_filebuf'
ResolvExpression() Match:'ifstream(ID=688) : type='basic_ifstream'
ResolvExpression() Match:'ofstream(ID=689) : type='basic_ofstream'
ResolvExpression() Match:'fstream(ID=690) : type='basic_fstream'

Loaden · « **Reply #22 on:** September 14, 2010, 03:14:54 am »

Quote from: ptDev on September 13, 2010, 01:36:59 pm

Quote from: Loaden on September 13, 2010, 11:41:00 am
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.

I fully repeat your steps given to reproduce, and tried 10 times, but can not reproduce again.
AND, I think this perhaps is not CC problem, It's maybe cbThreadPool issue.
XPSP3, MinGW 4.4.4, wx2.8.10

Loaden · « **Reply #23 on:** September 14, 2010, 03:20:27 am »

Quote from: ironhead on September 13, 2010, 04:40:20 pm

Here's what I see in the debug log:

Code

Create new parser for project '*NONE*'
Starting batch parsing for project '*NONE*'...
Project '*NONE*' parsing stage done!
Project '*NONE*' parsing stage done (1 total parsed files, 3 tokens in 0 minute(s), 0.000 seconds).
Updating class browser...
Class browser updated.

Could you confirm create project by wizard?
Please try open a project by "File > Open" ? and post the debug log in here.
Thanks!

ironhead · « **Reply #24 on:** September 14, 2010, 04:08:01 am »

Quote from: Loaden on September 14, 2010, 03:20:27 am

Quote from: ironhead on September 13, 2010, 04:40:20 pm
Here's what I see in the debug log:

Code
Create new parser for project '*NONE*'
Starting batch parsing for project '*NONE*'...
Project '*NONE*' parsing stage done!
Project '*NONE*' parsing stage done (1 total parsed files, 3 tokens in 0 minute(s), 0.000 seconds).
Updating class browser...
Class browser updated.
Could you confirm create project by wizard?
Please try open a project by "File > Open" ? and post the debug log in here.
Thanks!

I used the console wizard to create a console app using C++. With the default generated code:

Code

#include <iostream>

using namespace std;

int main()
{
    cout << "Hello world!" << endl;
    return 0;
}

When typing 'std::' on a new line, below is the resulting debug log:

Code

Reparsing when typing for editor C:\Users\Chris\Documents\test\main.cpp
Reparsing modified files for project 'test'
Project 'test' parsing stage done (2 total parsed files, 29 tokens in 0 minute(s), 0.000 seconds).
Updating class browser...
Class browser updated.
Reparsing when typing for editor C:\Users\Chris\Documents\test\main.cpp
Reparsing modified files for project 'test'
Project 'test' parsing stage done (2 total parsed files, 29 tokens in 0 minute(s), 0.000 seconds).
Updating class browser...
Class browser updated.
MarkItemsByAI()
ParseUsingNamespace() Parse file scope for "using namespace"
BreakUpComponents() Breaking up 'std'
BreakUpComponents() Found component: 'std' (SearchText)
BreakUpComponents() Adding component: 'std'.
ParseFunctionArguments() Parse function arguments
FindCurrentFunctionStart() Looking for tokens in 'C:\Users\Chris\Documents\test\main.cpp'
FindCurrentFunctionStart() Found 1 results
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int main()', tF='C:\Users\Chris\Documents\test\main.cpp', tStart=6, tEnd=10
FindCurrentFunctionStart() Current function: 'int main()' (at line 5)
FindCurrentFunctionStart() Namespace='', proc='main' (returning 59)
GenerateResultSet() search 'main', parent='Global namespace (id:0, type:(null)), isPrefix=0'
ParseFunctionArguments() + Function match: main
ParseLocalBlock() Parse local block
FindCurrentFunctionStart() Looking for tokens in 'C:\Users\Chris\Documents\test\main.cpp'
FindCurrentFunctionStart() Found 1 results
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int main()', tF='C:\Users\Chris\Documents\test\main.cpp', tStart=6, tEnd=10
FindCurrentFunctionStart() Current function: 'int main()' (at line 5)
FindCurrentFunctionStart() Namespace='', proc='main' (returning 59)
ParseLocalBlock() Block:

  std::
ParseLocalBlock() Local tokens:
AI() =========================================================
AI() Doing AI for '  std::':
FindCurrentFunctionStart() Looking for tokens in 'C:\Users\Chris\Documents\test\main.cpp'
FindCurrentFunctionStart() Found 1 results
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int main()', tF='C:\Users\Chris\Documents\test\main.cpp', tStart=6, tEnd=10
FindCurrentFunctionStart() Current function: 'int main()' (at line 5)
FindCurrentFunctionStart() Namespace='', proc='main' (returning 59)
GenerateResultSet() search 'main', parent='Global namespace (id:0, type:(null)), isPrefix=0'
AI() Adding search namespace: Global namespace
BreakUpComponents() Breaking up '  std::'
BreakUpComponents() Found component: 'std' (Namespace)
BreakUpComponents() Adding component: 'std'.
BreakUpComponents() Found component: '' (SearchText)
BreakUpComponents() Adding component: ''.
ResolveExpression() search scope is 1 result.
search scope: -1
ResolveExpression() Looping 0 result.
AI() AI leave, returned 0 results
0 results

How do I check if 'std' is in my tokentree?

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.

ironhead · « **Reply #25 on:** September 14, 2010, 04:40:59 am »

I finally got 'std' to complete, I had to manually add all the compiler search paths:

Code

C:\MinGW64\include
C:\MinGW64\x86_64-w64-mingw32\include
C:\MinGW64\lib\gcc\x86_64-w64-mingw32\4.5.2\include
C:\MinGW64\lib\gcc\x86_64-w64-mingw32\4.5.2\include-fixed
C:\MinGW64\mingw\include
C:\MinGW64\include\c++\4.5.2
C:\MinGW64\include\c++\4.5.2\x86_64-w64-mingw32
C:\MinGW64\include\c++\4.5.2\backward

Now that I have this working, I have to say, Loaden, olly, Blueshake and company, you have done an excellent job in improving CC!

Loaden · « **Reply #26 on:** September 14, 2010, 05:42:35 am »

Quote from: ironhead on September 14, 2010, 04:40:59 am

I finally got 'std' to complete, I had to manually add all the compiler search paths:

Code
C:\MinGW64\include
C:\MinGW64\x86_64-w64-mingw32\include
C:\MinGW64\lib\gcc\x86_64-w64-mingw32\4.5.2\include
C:\MinGW64\lib\gcc\x86_64-w64-mingw32\4.5.2\include-fixed
C:\MinGW64\mingw\include
C:\MinGW64\include\c++\4.5.2
C:\MinGW64\include\c++\4.5.2\x86_64-w64-mingw32
C:\MinGW64\include\c++\4.5.2\backward
Now that I have this working, I have to say, Loaden, olly, Blueshake and company, you have done an excellent job in improving CC!

Could you trying this portable build?

Hi, all, if you have some problem in CC-BRANCH, please trying this build.
1. Run "test.bat", start CB.
2. Do some thing that you want.
3. Close CB, will create two log files.
4. Please package all the log files, and post in here.
Thanks a lot!

http://portablecb.googlecode.com/files/CB_CCBRANCH_6599_patched.7z

This is a portable build, all configurations are in the "config" directory. If you need restart test, just remove "config".

Here is the "test.bat" content:

Quote

@echo off
if exist codeblocks.exe start codeblocks.exe --debug-log --debug-log-to-file --log-to-file

2010-09-17 11:15:01 UPDATE: instead by http://portablecb.googlecode.com/files/CB_CCBRANCH_6599_patched.7z

Loaden · « **Reply #27 on:** September 14, 2010, 05:59:13 am »

Quote from: ptDev on September 13, 2010, 01:36:59 pm

Quote from: Loaden on September 13, 2010, 11:41:00 am
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

ptDev · « **Reply #28 on:** September 14, 2010, 08:53:12 am »

Quote from: Loaden on September 14, 2010, 05:59:13 am

Quote from: ptDev on September 13, 2010, 01:36:59 pm
Quote from: Loaden on September 13, 2010, 11:41:00 am
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.

daniloz · « **Reply #29 on:** September 14, 2010, 09:00:29 am »

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,

ollydbg · « **Reply #30 on:** September 14, 2010, 09:05:12 am »

Quote from: daniloz on September 14, 2010, 09:00:29 am

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 · « **Reply #31 on:** September 14, 2010, 09:50:50 am »

Quote from: daniloz on September 14, 2010, 09:00:29 am

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 · « **Reply #32 on:** September 14, 2010, 10:07:21 am »

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

killerbot · « **Reply #33 on:** September 14, 2010, 10:26:17 am »

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 · « **Reply #34 on:** September 15, 2010, 02:34:57 am »

Quote from: Orgulas on September 13, 2010, 08:28:18 pm

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 · « **Reply #35 on:** September 15, 2010, 02:40:57 am »

Quote from: ironhead on September 14, 2010, 04:08:01 am

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 · « **Reply #36 on:** September 15, 2010, 07:31:02 am »

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 · « **Reply #37 on:** September 15, 2010, 07:33:39 am »

Quote from: ollydbg on September 15, 2010, 02:40:57 am

Quote from: ironhead on September 14, 2010, 04:08:01 am
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 · « **Reply #38 on:** September 15, 2010, 07:35:18 am »

Quote from: killerbot on September 14, 2010, 10:26:17 am

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 · « **Reply #39 on:** September 15, 2010, 01:20:11 pm »

Quote from: Loaden on September 15, 2010, 07:33:39 am

Quote from: ollydbg on September 15, 2010, 02:40:57 am
Quote from: ironhead on September 14, 2010, 04:08:01 am
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 · « **Reply #40 on:** September 15, 2010, 02:14:48 pm »

Quote from: ironhead on September 15, 2010, 01:20:11 pm

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 · « **Reply #41 on:** September 16, 2010, 04:19:10 am »

Quote from: Loaden on September 15, 2010, 02:14:48 pm

Quote from: ironhead on September 15, 2010, 01:20:11 pm
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 · « **Reply #42 on:** September 16, 2010, 04:20:39 am »

Quote from: ptDev on September 14, 2010, 08:53:12 am

Quote from: Loaden on September 14, 2010, 05:59:13 am
Quote from: ptDev on September 13, 2010, 01:36:59 pm
Quote from: Loaden on September 13, 2010, 11:41:00 am
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 · « **Reply #43 on:** September 16, 2010, 04:31:10 am »

Quote from: ironhead on September 16, 2010, 04:19:10 am

Quote from: Loaden on September 15, 2010, 02:14:48 pm
Quote from: ironhead on September 15, 2010, 01:20:11 pm
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!

Quote

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 · « **Reply #44 on:** September 16, 2010, 08:25:11 am »

Quote from: killerbot on September 14, 2010, 10:26:17 am

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.

ptDev · « **Reply #45 on:** September 16, 2010, 09:05:16 am »

Quote from: Loaden on September 16, 2010, 04:20:39 am

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

Tried, the issue is gone.
Confirmed as fixed.

Loaden · « **Reply #46 on:** September 17, 2010, 05:14:55 am »

1. Redesign the parser one by one
2. Improve the protection of critical section
http://portablecb.googlecode.com/files/CB_CCBRANCH_6599_patched.7z

Loaden · « **Reply #47 on:** September 17, 2010, 08:20:26 am »

Fix buf of scope select failed in linux.

Loaden · « **Reply #48 on:** September 18, 2010, 12:47:22 pm »

avoiding some times crash

News:

Author Topic: The 12 september 2010 build (6583) CODECOMPLETION BRANCH version is out. (Read 70891 times)