Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on September 01, 2015, 10:14:44 pm

Title: The 01 September 2015 build (10474) is out.
Post by: killerbot on September 01, 2015, 10:14:44 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 (http://forums.codeblocks.org/index.php/topic,3232.0.html).

A link to the unicode windows wxWidget dll for Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw28u_gcc_cb_wx2812_gcc492-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/mingwm10_gcc492-TDM.7z

The 01 September 2015 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2015/CB_20150901_rev10474_win32.7z
  - Linux :
   none

The current SDK version is : 1.26.0

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 01 September 2015 build (10474) is out.
Post by: Jenna on September 02, 2015, 06:06:10 am
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (https://apt.jenslody.de/).
These packages are build against wxWidgets 3.0 from Debian repos and mght not be as stable than the versions build against wx2.8, but there are no wx2.8 packages available (at least for stable) from official repos.
Please test and give feedback.

Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc21, fc22, fc23 and rawhide), RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) and RedHat/CentOS 7 packages (64-bit) can be found in my rpm-repo (https://copr.fedoraproject.org/coprs/jenslody/).
I recently switched to copr (https://copr.fedoraproject.org/) to build and host my Fedora and CentOS packages.
Instructions how to use it can be found on my server (https://rpm.jenslody.de/) (easier) or on copr (https://copr.fedoraproject.org/coprs/jenslody/) (a little more handwork needed).
Title: Re: The 01 September 2015 build (10474) is out.
Post by: MortenMacFly on September 02, 2015, 12:21:29 pm
Installers (for Windows):

http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2015/CB_20150901_rev10474_win32_setup.exe
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2015/CB_20150901_rev10474_win32_setup.zip

(May need some time to appear on SF, so please be patient...)
Title: Re: The 01 September 2015 build (10474) is out.
Post by: carra on September 02, 2015, 01:31:32 pm
Seems to run fine under windows :)

I can report news regarding the issues I posted here (http://forums.codeblocks.org/index.php/topic,20548.0.html):
Title: Re: The 01 September 2015 build (10474) is out.
Post by: shurick on September 02, 2015, 05:22:11 pm
Packages for openSUSE (http://codeblocks.esy.es) (binaries and sources) for 32-bit and 64-bit.
Title: Re: The 01 September 2015 build (10474) is out.
Post by: ollydbg on September 03, 2015, 02:37:45 am
Seems to run fine under windows :)

I can report news regarding the issues I posted here (http://forums.codeblocks.org/index.php/topic,20548.0.html):
  • As you can see in image 1, the error when using initializers has been corrected
  • I have verified (see image 2) that CC parsers actually ARE recognising all members of my classes right!
Good to hear. :)

Quote
However, for classes not belonging to the current project, it fails to show any suggestions. In the image, when I typed "V55.", code completion did not show its members...[/li]
[/list]
How can I reproduce your bug, are there any sample code snippet?
EDIT: if a file is not belong to the active project, then its content is not parsed(if you enable the option as one parser for a project)



Title: Re: The 01 September 2015 build (10474) is out.
Post by: carra on September 03, 2015, 12:20:27 pm
Quote
How can I reproduce your bug, are there any sample code snippet?
Sure, I have attached here a ZIP file of a very simple project where this happens (see the image). The error seems to come from namespaces: code completion triggers as expected if I simply define the following class and use it in Main.cpp

Code
namespace Math
{
    class Vector2D{ ... };
}

However when the class is exported into another namespace, and a source file uses this second namespace, code completion will not trigger.
Title: Re: The 01 September 2015 build (10474) is out.
Post by: ollydbg on September 04, 2015, 01:14:25 am
Quote
How can I reproduce your bug, are there any sample code snippet?
Sure, I have attached here a ZIP file of a very simple project where this happens (see the image). The error seems to come from namespaces: code completion triggers as expected if I simply define the following class and use it in Main.cpp

Code
namespace Math
{
    class Vector2D{ ... };
}

However when the class is exported into another namespace, and a source file uses this second namespace, code completion will not trigger.
OK, I can confirm it, this is a bug in CC, since CC doesn't handle the namespace export command. (CC just skip that statement).
Please report to the sourceforge ticket with the sample code, so that this bug won't get lost. Thanks.

About how to fix this bug, I don't have a clean idea, maybe, we need to remember the exported symbol as a child symbol in a namespace token? Maybe, we need a special field of the namespace token.
Title: Re: The 01 September 2015 build (10474) is out.
Post by: carra on September 04, 2015, 07:40:47 am
Glad you can reproduce it Olly. I created the ticket, it's number #208.

About the way to fix it, I have no idea of how CC works. But since the old one had always handled this case correctly, maybe you can see how it was done back then.

Also, I seem to have messed the formatting badly in the ticket description, and there doesn't seem to be any way to edit it. If you are an admin there, feel free to correct it ;)
Title: Re: The 01 September 2015 build (10474) is out.
Post by: ollydbg on September 04, 2015, 09:30:33 am
Glad you can reproduce it Olly. I created the ticket, it's number #208.

About the way to fix it, I have no idea of how CC works. But since the old one had always handled this case correctly, maybe you can see how it was done back then.
Really? But I think CC has never handle this case before, which revision did you see works OK?

Quote
Also, I seem to have messed the formatting badly in the ticket description, and there doesn't seem to be any way to edit it. If you are an admin there, feel free to correct it ;)
Done. Thanks.
Title: Re: The 01 September 2015 build (10474) is out.
Post by: carra on September 04, 2015, 12:52:54 pm
Really? But I think CC has never handle this case before, which revision did you see works OK?
Wow, you are actually right! :o I have tested it in version 8242, which I used for a long time, and the bug is there too!! My guess is that I wasn't using this pattern in my headers at that time, and that I must have started using it just after switching to some newer version (that's why I believed the new CC to be the culprit).
Title: Re: The 01 September 2015 build (10474) is out.
Post by: Xaviou on September 04, 2015, 04:28:17 pm
Hi to all.

I probably found a small bug in this release.
The "Insert" => "All class methods without implementation" functionality of the editor removes the spaces between the parameters names and their types.

Step to reproduce :
The declaration of the function is void OnClose(wxCloseEvent& event); (note the space between wxCloseEvent& and event).
In the cpp file, the inserted method is now void OnClose(wxCloseEvent&event); (the space has been removed).

I've made some test with the previous nightly (r10376) but the bug wasn't present.

I also noticed that an old bug is still present : if in a class you have a method witch returns a pointer or a reference (for example wxString& GetAppPath()), the automatically inserted function with the Insert => All class methods without implementation doesn't have the correct type (the * or & sign is removed and the inserted text will be wxString wxCBTestFrame::GetAppPath()).

Regards
Xav'.
Title: Re: The 01 September 2015 build (10474) is out.
Post by: ollydbg on September 05, 2015, 02:28:01 am
Hi to all.

I probably found a small bug in this release.
The "Insert" => "All class methods without implementation" functionality of the editor removes the spaces between the parameters names and their types.

Step to reproduce :
  • Create a new wxWidgets project (frame based) : let's name it wxCBTest
  • Open the frame's cpp file in the editor, and remove one of the events handlers (for example, remove all the implementation of wxCBTestFrame::OnClose) but don't touch the declaration.
  • Press [ Ctrl ] + [ Alt ] + [ S ] to save all the files (or press the "Save all files" toolbar button)
  • Right click in an empty line in the editor (witch should always be open on the frame's cpp file)
  • Select Insert => All class methods without implementation
  • The removed function should be present in the list : select it (and unselect others things if any)
The declaration of the function is void OnClose(wxCloseEvent& event); (note the space between wxCloseEvent& and event).
In the cpp file, the inserted method is now void OnClose(wxCloseEvent&event); (the space has been removed).

I've made some test with the previous nightly (r10376) but the bug wasn't present.
Hi, thanks for the report, I can confirm this, it is caused by my CC patch serials to enable the macro expansion. I will look into it.

Quote
I also noticed that an old bug is still present : if in a class you have a method witch returns a pointer or a reference (for example wxString& GetAppPath()), the automatically inserted function with the Insert => All class methods without implementation doesn't have the correct type (the * or & sign is removed and the inserted text will be wxString wxCBTestFrame::GetAppPath()).

Regards
Xav'.
It is another bug as I can see, I will look into it also.
Title: Re: The 01 September 2015 build (10474) is out.
Post by: ollydbg on September 05, 2015, 02:35:46 am
Hi, thanks for the report, I can confirm this, it is caused by my CC patch serials to enable the macro expansion. I will look into it.
The issue is caused by reading the parentheses, I just look at the token, I see that:
Code
$4 = {m_FullType = L"void", m_BaseType = L"void", m_Name = L"OnAbout", m_Args = L"(wxCommandEvent&event)", m_BaseArgs = L"(wxCommandEvent&)", m_AncestorsString = <g_strEmpty+12> L"", m_FileIdx = 293, m_Line = 31, m_ImplFileIdx = 0, m_ImplLine = 0, m_ImplLineStart = 100, m_ImplLineEnd = 102, m_Scope = tsPrivate, m_TokenKind = tkFunction, m_IsOperator = false, m_IsLocal = true, m_IsTemp = false, m_IsConst = false, m_IsNoExcept = false, m_IsAnonymous = false, m_Index = 68154, m_ParentIndex = 68149, m_Children = std::set with 0 elements, m_Ancestors = std::set with 0 elements, m_DirectAncestors = std::set with 0 elements, m_Descendants = std::set with 0 elements, m_Aliases = wxArray<T>, m_TemplateArgument = <g_strEmpty+12> L"", m_TemplateType = wxArray<T>, m_TemplateMap = std::map with 0 elements, m_TemplateAlias = <g_strEmpty+12> L"", m_UserData = 0x3c54f80, m_TokenTree = 0x1234cc08, m_Ticket = 68489}
Look at the "m_Args" field.
Title: Re: The 01 September 2015 build (10474) is out.
Post by: ollydbg on September 05, 2015, 04:47:50 am
@Xaviou
The first issue is fixed in trunk now.

The second issue is that it looks like the "*“ is lost in the Token. If I have a member function wxString * fff();
Then, I get such token:
Code
$3 = {m_FullType = L"wxString", m_BaseType = L"wxString", m_Name = L"fff", m_Args = L"()"
, m_BaseArgs = L"()", m_AncestorsString = <g_strEmpty+12> L"", m_FileIdx = 5, m_Line = 43, m_ImplFileIdx = 0, m_ImplLine = 0, m_ImplLineStart = 104, m_ImplLineEnd = 106, m_Scope = tsPrivate, m_TokenKind = tkFunction, m_IsOperator = false, m_IsLocal = true, m_IsTemp = false, m_IsConst = false, m_IsNoExcept = false, m_IsAnonymous = false, m_Index = 20415, m_ParentIndex = 20409
, m_Children = std::set with 0 elements, m_Ancestors = std::set with 0 elements, m_DirectAncestors = std::set with 0 elements, m_Descendants = std::set with 0 elements, m_Aliases = wxArray<T>, m_TemplateArgument = <g_strEmpty+12> L"", m_TemplateType = wxArray<T>, m_TemplateMap = std::map with 0 elements, m_TemplateAlias = <g_strEmpty+12> L"", m_UserData = 0x0, m_TokenTree = 0x12340458, m_Ticket = 68900}
This means either the m_FullType or the m_BaseType has no "*" information.
Title: Re: The 01 September 2015 build (10474) is out.
Post by: ollydbg on September 05, 2015, 07:29:06 am
The second issue is that it looks like the "*“ is lost in the Token.
...
Tested again, I see that "*" is only exists in "m_FullType", not in "m_BaseType", then with the following patch, you issue can be solved.
Code
 src/plugins/codecompletion/codecompletion.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/plugins/codecompletion/codecompletion.cpp b/src/plugins/codecompletion/codecompletion.cpp
index 4814840..8434566 100644
--- a/src/plugins/codecompletion/codecompletion.cpp
+++ b/src/plugins/codecompletion/codecompletion.cpp
@@ -2742,7 +2742,8 @@ int CodeCompletion::DoAllMethodsImpl()
                 str << ed->GetLineIndentString(line - 1);
             if (addDoxgenComment)
                 str << _T("/** @brief ") << token->m_Name << _T("\n  *\n  * @todo: document this function\n  */\n");
-            wxString type = token->m_BaseType;
+            wxString type = token->m_FullType;
+            // "int *" or "int &" ->  "int*" or "int&"
             if ((type.Last() == _T('&') || type.Last() == _T('*')) && type[type.Len() - 2] == _T(' '))
             {
                 type[type.Len() - 2] = type.Last();
I change the base type to full type.
Title: Re: The 01 September 2015 build (10474) is out.
Post by: Xaviou on September 05, 2015, 09:33:13 am
@Xaviou
The first issue is fixed in trunk now.
Thank you for your reactivity.

The second issue is that it looks like the "*“ is lost in the Token.
I don't know if it can help, but I've just saw that the dialog box witch allows to check/uncheck the missing methods we want to add has the correct definition.
Only the inserted code is wrong.

Regards
Xav'
Title: Re: The 01 September 2015 build (10474) is out.
Post by: ollydbg on September 05, 2015, 03:00:35 pm
...
Only the inserted code is wrong.
...
I fix this issue in rev10484.