Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on June 21, 2016, 08:46:31 pm

Title: The 21 June 2016 build (10868) is out.
Post by: killerbot on June 21, 2016, 08:46:31 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_gcc510-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_gcc510-TDM.7z

The 21 June 2016 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2016/CB_20160621_rev10868_win32.7z
  - Linux :
   none

The current SDK version is : 1.30.0

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 21 June 2016 build (10868) is out.
Post by: oBFusCATed on June 21, 2016, 10:11:50 pm
Does this build fix the problem with the new flag dialog in the compiler settings?
Title: Re: The 21 June 2016 build (10868) is out.
Post by: killerbot on June 21, 2016, 10:25:21 pm
the gcc 5 problem, I don't think anything has been done for that part.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: MortenMacFly on June 23, 2016, 07:38:44 am
Does this build fix the problem with the new flag dialog in the compiler settings?
What problem?
Title: Re: The 21 June 2016 build (10868) is out.
Post by: ollydbg on June 23, 2016, 08:15:06 am
Does this build fix the problem with the new flag dialog in the compiler settings?
What problem?
See here http://forums.codeblocks.org/index.php/topic,21207.msg144691.html#msg144691
Title: Re: The 21 June 2016 build (10868) is out.
Post by: eckard_klotz on June 26, 2016, 09:14:27 am
Hello Developers.

While starting this nightly (10868) I get an warning that one plug-in could not be loaded and in the log-tab I find the following content:
Quote
C:\Tool\Development\CodeBlocks\Nightlies\2016_06_21\bin\share\codeblocks\plugins\wxSmithContribItems.dll: not loaded (missing symbols?)

This happens on a laptop with win10 (frequently updated at least once a week) and Norton 360 Online as virus scanner. Please find attached the complete Code::Blocks log-tab content after starting.

Best regards,
                    Eckard.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: oBFusCATed on June 26, 2016, 10:24:49 am
Have you installed the night build in a new separate directory or you've overrode the old nightly with the files from the new one?
Title: Re: The 21 June 2016 build (10868) is out.
Post by: eckard_klotz on June 26, 2016, 01:45:44 pm
Hello oBFusCATed

 I install every nightly in its own sub folder.

Best regards,
                    Eckard.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: oBFusCATed on June 26, 2016, 10:32:45 pm
Thanks, this means that something is broken in the build. Anyone else seeing this problem?
Title: Re: The 21 June 2016 build (10868) is out.
Post by: eckard_klotz on June 27, 2016, 08:04:21 pm
Hello oBFusCATed.

In the meanwhile I recognized that there was no wxSmithContribItems.dll. After some investigation I found out that it was removed by my virus-scanner (Symantec Norton 360) as result of a heuristic check. I forced Norton to restore the dll and scanned it directly without a result. Thus I sent it to Symantec and reported it as a false positive.

I've got now a response that approves that it was realy a false positive:
Quote
...
In relation to submission [3967076].

Upon further analysis and investigation we have verified your submission and, as such, the detection(s) for the following file(s) will be removed from our products:

   Filename: wxspeedbutton.dll
   MD5: 102668EE5DAF98349C3980B532CB9053
   SHA256: AC6FA0579276CB1A928AF8C841C4660163B494EF4175E7DD8AD3018585BE3752
   Result:    Whitelisting for above file is taking effect from now on.





If detection persists, please contact support:
Norton: https://support.norton.com/sp/en/us/home/current/info
SEP: https://support.symantec.com/en_US/endpoint-protection.54619.html

Decisions made by Symantec are subject to change if alterations to the Software are made over time or as classification criteria and/or the policy employed by Symantec changes over time to address the evolving landscape.

If you are a software vendor and would like to upload your software for proactive whitelisting, please complete the following form: https://submit.symantec.com/whitelist/

For more information on best practices to reduce false positives:
http://www.symantec.com/content/en/us/enterprise/white_papers/b-to_increase_downloads-instill_trust_first_WP.en-us.pdf
...

After updating Norton it is not detecting the wxSmithContribItems.dll as suspicious any more and the nightly 10868 starts without problems.

Best regards,
                    Eckard.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: New Pagodi on June 28, 2016, 08:38:24 pm
On a similar note: AVG antivirus has also started falsely reporting wxspeedbutton.dll as a virus.

I just added an exception for it.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: Oleg_Sam on July 01, 2016, 07:23:31 am
This nightly build is crashes, when select global compiler options and right click to add new compiler flag for SDCC compiler on Windows7 platform. :'(

Title: Re: The 21 June 2016 build (10868) is out.
Post by: raynebc on July 01, 2016, 07:39:00 am
That crash is a known issue:
http://forums.codeblocks.org/index.php/topic,21090.msg144241.html#msg144241

Avast just started throwing false positives with this nightly as well.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: ollydbg on July 01, 2016, 09:30:10 am
This nightly build is crashes, when select global compiler options and right click to add new compiler flag for SDCC compiler on Windows7 platform. :'(
It should be the bug report here: SVN build crashes when trying to editing/adding new compiler flags (http://forums.codeblocks.org/index.php/topic,21207.0.html)
Title: Re: The 21 June 2016 build (10868) is out.
Post by: Oleg_Sam on July 22, 2016, 01:34:50 pm
The build-ins variables $(PROJECT_FILE), $(PROJECT_NAME), $(PROJECT_DIR) is not changed when reloading projects. To reproduce this bug:
1. Create Console application test1.
2. Open Project build option->Pre/post build steps
3. Add Pre build steps
     echo $(PROJECT_FILE)
     echo $(PROJECT_NAME)
     echo $(PROJECT_DIR)
4. Save project test1
5. Close project test1
6. Repeat steps 1..5 for project test2
7. Load project test1
8. Rebuild test1
9. Look at the build log and see that  build-ins variables is correct (test1).
10. Close Project test1
11. Load project test2
12. Rebuild test2
13. Look at the build log and see that  build-ins variables is not correct (test1).
      Its not changed and must be test2.

This bug is in all versions CB from 16.01.
My platform is Windows7 32 bit.
 
Title: Re: The 21 June 2016 build (10868) is out.
Post by: Pecan on July 25, 2016, 09:09:30 pm
When a workspace with only one project is closed, then another loaded, it's possible for the newly loaded project to be assigned the same memory address as the closed project.

Thus, any test against the previously loaded projects address will match, and macrosmanager.cpp will not replace the macros for the second project.
 
Below is the fix. I'll apply after review by other team members.
 
Code
Index: src/sdk/macrosmanager.cpp
===================================================================
--- src/sdk/macrosmanager.cpp (revision 10889)
+++ src/sdk/macrosmanager.cpp (working copy)
@@ -269,7 +269,7 @@
         m_Macros[_T("MAKEFILE")]             = wxEmptyString;
         m_Macros[_T("ALL_PROJECT_FILES")]    = wxEmptyString;
     }
-    else if (project != m_LastProject)
+    else if ( (project != m_LastProject) or (project->GetTitle() != m_ProjectName) )
     {
         m_LastTarget      = nullptr; // reset last target when project changes
         m_ProjectWxFileName.Assign(project->GetFilename());
@@ -340,7 +340,7 @@
         m_TargetFilename       = wxEmptyString;
         m_LastTarget           = nullptr;
     }
-    else if (target != m_LastTarget)
+    else if ( (target != m_LastTarget) or (target->GetTitle() != m_TargetName) )
     {
         wxFileName tod(target->GetOutputFilename());
         m_TargetOutputDir      = UnixFilename(tod.GetPath(wxPATH_GET_VOLUME | wxPATH_GET_SEPARATOR));
@@ -455,7 +455,8 @@
                 target = project->GetBuildTarget(project->GetActiveBuildTarget());
         }
     }
-    if (project != m_LastProject || target != m_LastTarget || (editor && (editor->GetFilename() != m_ActiveEditorFilename)) )
+    if (project != m_LastProject || target != m_LastTarget || (editor && (editor->GetFilename() != m_ActiveEditorFilename))
+         || (project && (project->GetTitle() != m_ProjectName)) || (target && (target->GetTitle() != m_TargetName)) )
         RecalcVars(project, editor, target);
 
     wxString search;
Title: Re: The 21 June 2016 build (10868) is out.
Post by: blauzahn on July 26, 2016, 06:37:55 am
What if the checked attributes of the 2 projects are the same? This is quite probable when
you load a different version of the same project (e.g. a backup). Ideally, the
solution does not depend on any attribute at all. Would it make sense to set
m_LastProject to nullptr on close or would that contradict its purpose?

Until then, I welcome an improvement like yours.

Title: Re: The 21 June 2016 build (10868) is out.
Post by: Pecan on July 26, 2016, 06:48:02 pm
What if the checked attributes of the 2 projects are the same? ...

Good point.
So, we need a unique attribute.

Question: Is it always true that the absolute form of the project filename (.cbp) is unique for all projects?

Title: Re: The 21 June 2016 build (10868) is out.
Post by: Pecan on July 27, 2016, 06:54:43 pm
What if the checked attributes of the 2 projects are the same?

New patch to assure that the secondary attribute comparison is unique.
Also using the shorter comparisons first as a short circuit to the result.

Code
Index: src/sdk/macrosmanager.cpp
===================================================================
--- src/sdk/macrosmanager.cpp (revision 10889)
+++ src/sdk/macrosmanager.cpp (working copy)
@@ -269,7 +269,10 @@
         m_Macros[_T("MAKEFILE")]             = wxEmptyString;
         m_Macros[_T("ALL_PROJECT_FILES")]    = wxEmptyString;
     }
-    else if (project != m_LastProject)
+    else if ( (project != m_LastProject) || (project->GetTitle() != m_ProjectName)
+                || (UnixFilename(project->GetBasePath()) != m_ProjectDir)
+                || (UnixFilename(project->GetFilename()) != m_ProjectFilename)
+             )
     {
         m_LastTarget      = nullptr; // reset last target when project changes
         m_ProjectWxFileName.Assign(project->GetFilename());
@@ -340,7 +343,7 @@
         m_TargetFilename       = wxEmptyString;
         m_LastTarget           = nullptr;
     }
-    else if (target != m_LastTarget)
+    else if ( (target != m_LastTarget) or (target->GetTitle() != m_TargetName) )
     {
         wxFileName tod(target->GetOutputFilename());
         m_TargetOutputDir      = UnixFilename(tod.GetPath(wxPATH_GET_VOLUME | wxPATH_GET_SEPARATOR));
@@ -455,7 +458,10 @@
                 target = project->GetBuildTarget(project->GetActiveBuildTarget());
         }
     }
-    if (project != m_LastProject || target != m_LastTarget || (editor && (editor->GetFilename() != m_ActiveEditorFilename)) )
+    if ( (project != m_LastProject) || (target != m_LastTarget) || (editor && (editor->GetFilename() != m_ActiveEditorFilename))
+            || (project && (UnixFilename(project->GetBasePath()) != m_ProjectDir))
+            || (project && (UnixFilename(project->GetFilename()) != m_ProjectFilename))
+            || (target && (target->GetTitle() != m_TargetName)) )
         RecalcVars(project, editor, target);
 
     wxString search;
Title: Re: The 21 June 2016 build (10868) is out.
Post by: Oleg_Sam on July 29, 2016, 12:40:43 pm
Thank you for this patch. Now its all work fine!
Title: Re: The 21 June 2016 build (10868) is out.
Post by: Pecan on July 31, 2016, 12:20:10 am
Corrected patch.
Comparison on m_ProjectFilename was incorrect.


Code
Index: src/sdk/macrosmanager.cpp
===================================================================
--- src/sdk/macrosmanager.cpp (revision 10889)
+++ src/sdk/macrosmanager.cpp (working copy)
@@ -269,7 +269,10 @@
         m_Macros[_T("MAKEFILE")]             = wxEmptyString;
         m_Macros[_T("ALL_PROJECT_FILES")]    = wxEmptyString;
     }
-    else if (project != m_LastProject)
+    else if ( (project != m_LastProject) || (project->GetTitle() != m_ProjectName)
+                || (UnixFilename(project->GetBasePath()) != m_ProjectDir)
+                || (UnixFilename(m_ProjectWxFileName.GetFullName()) != m_ProjectFilename)
+             )
     {
         m_LastTarget      = nullptr; // reset last target when project changes
         m_ProjectWxFileName.Assign(project->GetFilename());
@@ -340,7 +343,7 @@
         m_TargetFilename       = wxEmptyString;
         m_LastTarget           = nullptr;
     }
-    else if (target != m_LastTarget)
+    else if ( (target != m_LastTarget) or (target->GetTitle() != m_TargetName) )
     {
         wxFileName tod(target->GetOutputFilename());
         m_TargetOutputDir      = UnixFilename(tod.GetPath(wxPATH_GET_VOLUME | wxPATH_GET_SEPARATOR));
@@ -455,7 +458,10 @@
                 target = project->GetBuildTarget(project->GetActiveBuildTarget());
         }
     }
-    if (project != m_LastProject || target != m_LastTarget || (editor && (editor->GetFilename() != m_ActiveEditorFilename)) )
+    if (project != m_LastProject || target != m_LastTarget || (editor && (editor->GetFilename() != m_ActiveEditorFilename))
+                    || (project && (UnixFilename(project->GetBasePath()) != m_ProjectDir))
+                    || (UnixFilename(m_ProjectWxFileName.GetFullName()) != m_ProjectFilename)
+                    || (target && (target->GetTitle() != m_TargetName)) )
         RecalcVars(project, editor, target);
 
     wxString search;
Title: Re: The 21 June 2016 build (10868) is out.
Post by: oBFusCATed on August 02, 2016, 03:56:35 am
Why don't you detect project close event and set the m_lastproject to null?
Title: Re: The 21 June 2016 build (10868) is out.
Post by: Pecan on August 02, 2016, 07:49:55 pm
Why don't you detect project close event and set the m_lastproject to null?

cbEvent_Project_Closed is not called during the compilation of a workspace.
The macros have to be reset before compilation of a project in a workspace.

I'll try working with WorkSpaceChanged() event. But macrosmanager get called in so many places outside of events..... the conditions are mind boggling.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: oBFusCATed on August 02, 2016, 09:01:37 pm
You can leave the pointer comparison probably, just make sure that the pointer is reset when there is no project loaded. Everything else should probably stay the same.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: Pecan on August 03, 2016, 05:30:04 pm
You can leave the pointer comparison probably, just make sure that the pointer is reset when there is no project loaded. Everything else should probably stay the same.

I have spent hours trapping events, hoping to find one that could be used to reliably reset the old project pointer in macros manager. 

Unfortunately, there is no CB event that can be used to reliably reset the last project pointer to zero when multiple projects exist within a workspace and the user does a full workspace build.

The pointer must be reset between compiles of projects within a workspace as well as project activation, open and close.

The compiler events can be used to reset the pointer just before a compile, but these events are (erroneously) invoked by the CodeCompletion plugin so many times it's a turkey shoot to figure out if it's a CodeCompletion call or a real request for compilation. The current comparisons are less overhead then resetting the project pointer for erroneous compilation events.

Using complilation events would also miss the needed project events reset.

The current patch is the only method I can find to reliably reset the old project pointer for both api macro translation calls (cb core, plugins, scripts, etc) and which catch all events that require macro translation.

I welcome further suggestions.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: oBFusCATed on August 03, 2016, 09:10:00 pm
The current comparisons are less overhead then resetting the project pointer for erroneous compilation events.
I'm concerned about the robustness and not the performance. I'll give it a try hopefully soon.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: Andy356 on August 11, 2016, 06:18:02 pm
Hi guys,

I just noticed that -std=c11 is not available as a standard compiler flag. It's trivial to enable it in "Other compiler options", or add it as a new flag, but still, it should be a flag provided by default...

Edit: The compiler is GCC 6.1. The man page lists c11 as a valid flag. (Thanks, stahta01)
Title: Re: The 21 June 2016 build (10868) is out.
Post by: stahta01 on August 11, 2016, 07:13:22 pm
FYI: Compiler flags are per compiler; you should state which compiler is missing the option that needs it.

Hi guys,

I just noticed that -std=c11 is not available as a standard compiler flag. It's trivial to enable it in "Other compiler options", or add it as a new flag, but still, it should be a flag provided by default...
Title: Re: The 21 June 2016 build (10868) is out.
Post by: pcoquill on August 24, 2016, 12:51:25 pm
Hi,
My antivirus (AVG) indicates the presence of a trojan virus in one dll: Inject3.AVPH.
Any information about this ?

Regards, Patrick
Title: Re: The 21 June 2016 build (10868) is out.
Post by: Jenna on August 24, 2016, 10:37:21 pm
Hi,
My antivirus (AVG) indicates the presence of a trojan virus in one dll: Inject3.AVPH.
Any information about this ?

Regards, Patrick
Most likely a false positive (not the first one).

You should test it on http://virustotal.com .
Title: Re: The 21 June 2016 build (10868) is out.
Post by: Andy356 on September 08, 2016, 01:27:51 am
On the latest Codeblocks for Debian (svn 10887), I used it and then tried to close the program just now. It didn't respond at first. Then while I was repeatedly clicking the close button, it suddenly closed and was replaced with a dialog asking to generate a debug report. It is an xml file and is resting in the tmp folder. Codeblocks has resumed its normal behaviour. What should I do? Ignore it, or post the bug report? And how do I go about posting it if required?
Title: Re: The 21 June 2016 build (10868) is out.
Post by: oBFusCATed on September 08, 2016, 08:30:35 am
Does it happen all the time or was a single event?
The easiest thing you can do is attach the xml file to a forum post or use pastebin service to upload it to.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: Andy356 on September 09, 2016, 09:25:28 pm
Oh... This is embarrassing. The file is gone. It was in the /tmp folder, so in hindsight, I should have saved it elsewhere. My bad.

But anyway, it has never occurred before, and hasn't happened again yet. Singular event, so far.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: UberNewb on October 06, 2016, 08:32:13 pm
Hello CB team! First off, just want to thank you guys for your continued work and progress on making CB great!

I have a couple issues I was hoping you guys could help me resolve.

Issue #1. There are fairly common errors in the CodeCompletion ability of CB. I type the first few letters and get a matching completion in the popup box, but then when I press enter it fills in an incorrect entry. It is like it is using the wrong index of the entry. Something that might be affecting it is when the popup overlaps the bottom of the CB window and not all entries are shown. Also, once in a while there will be empty space in the code completion popup where an entry should be, and part of the widget is missing.

Issue #2 (Possible feature request). I mentioned this a long time ago, but it must have gotten lost in the shuffle or was not a priority, but I would like to request a re-linking option in the build menu. I have several dependent libraries and projects that work together in the same workspace, and when I update a dependent library, I have to fully rebuild a dependent project to get it to re-link to the library. If there was a menu shortcut for re-linking that would be awesome I think.

I'm using 10868 Nightly with Windows 10 currently.

Anyway, love the work you guys are doing! CB is awesome! Waaaay better than MSVS if you ask me. ;)

Title: Re: The 21 June 2016 build (10868) is out.
Post by: stahta01 on October 06, 2016, 10:58:06 pm
SNIP

Issue #2 (Possible feature request). I mentioned this a long time ago, but it must have gotten lost in the shuffle or was not a priority, but I would like to request a re-linking option in the build menu. I have several dependent libraries and projects that work together in the same workspace, and when I update a dependent library, I have to fully rebuild a dependent project to get it to re-link to the library. If there was a menu shortcut for re-linking that would be awesome I think.

I'm using 10868 Nightly with Windows 10 currently.

Anyway, love the work you guys are doing! CB is awesome! Waaaay better than MSVS if you ask me. ;)

Do you know about external dependencies in Code::Blocks because it fixes your item 2 for me.

Edit: I am NOT talking about project dependencies that are saved in the workspace file.

Tim S.
 
Title: Re: The 21 June 2016 build (10868) is out.
Post by: oBFusCATed on October 07, 2016, 12:44:09 am
Issue #1. There are fairly common errors in the CodeCompletion ability of CB. I type the first few letters and get a matching completion in the popup box, but then when I press enter it fills in an incorrect entry. It is like it is using the wrong index of the entry.
I've seen this several times, but I don't know how to reliably reproduce it.
Do you happen to know how to do it every time? If you know then I'll do my best to fix it.

Title: Re: The 21 June 2016 build (10868) is out.
Post by: yvesdm3000 on October 07, 2016, 06:26:21 pm
Issue #1. There are fairly common errors in the CodeCompletion ability of CB. I type the first few letters and get a matching completion in the popup box, but then when I press enter it fills in an incorrect entry. It is like it is using the wrong index of the entry.
I've seen this several times, but I don't know how to reliably reproduce it.
Do you happen to know how to do it every time? If you know then I'll do my best to fix it.
On occasion I see the exact same thing in my ClangCC plugin. I always assumed it was some sort of synchronization problem between an update and code completion, but now I'm unsure this is the case...

Yves
Title: Re: The 21 June 2016 build (10868) is out.
Post by: UberNewb on October 09, 2016, 08:00:33 pm

Issue #2 (Possible feature request). I mentioned this a long time ago, but it must have gotten lost in the shuffle or was not a priority, but I would like to request a re-linking option in the build menu. I have several dependent libraries and projects that work together in the same workspace, and when I update a dependent library, I have to fully rebuild a dependent project to get it to re-link to the library. If there was a menu shortcut for re-linking that would be awesome I think.


Do you know about external dependencies in Code::Blocks because it fixes your item 2 for me.

Edit: I am NOT talking about project dependencies that are saved in the workspace file.

Tim S.

I did not know about that. It looks like it will do the trick. Thanks.

Quote from: oBFusCATed
Quote from: UberNewb
    Issue #1. There are fairly common errors in the CodeCompletion ability of CB. I type the first few letters and get a matching completion in the popup box, but then when I press enter it fills in an incorrect entry. It is like it is using the wrong index of the entry.
I've seen this several times, but I don't know how to reliably reproduce it.
Do you happen to know how to do it every time? If you know then I'll do my best to fix it.
I can't reliably reproduce it except when it happens. About 90% of the time it works fine, but when it does fail, it fails the same way repeatedly. I'll try to come up with an example of it, but it may have to do with the large number of symbols in my library. If I can come up with a small example I'll post it.

Title: Re: The 21 June 2016 build (10868) is out.
Post by: oBFusCATed on October 09, 2016, 08:07:46 pm
I can't reliably reproduce it except when it happens. About 90% of the time it works fine, but when it does fail, it fails the same way repeatedly.
What do you mean by repeatedly here? The problem doesn't go away until you restart C::B, right?
Title: Re: The 21 June 2016 build (10868) is out.
Post by: UberNewb on October 11, 2016, 01:28:11 am
When I say repeatedly, it will fail the same way on the same code completion. Say I am typing 'WidgetBase', it will have the list of suggestions and point to the correct one, but then when I press enter it selects another one on the same list of suggestions. If I type WidgetBase again, and do it the same way, it will fail the same way. But I don't know how to make it happen. Sometimes it does, and sometimes it doesn't. I haven't come across it again yet, but I haven't been coding much the last few days. I'll let you know the next time it happens. I've never tried restarting so I don't know if that affects it.



Title: Re: The 21 June 2016 build (10868) is out.
Post by: oBFusCATed on October 11, 2016, 07:22:56 pm
I've never tried restarting so I don't know if that affects it.
Restarting fixes it for me. I'll be happy if you can confirm this. I'll be happier if you can find the exact steps needed to reproduce it.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: UberNewb on October 21, 2016, 11:25:12 pm
It hasn't happened again so far, so I can't confirm it yet.

However, I came across a newer and different parsing problem.

I was looking at the code completion for a function of mine named PinLayout::SetPinPosition and the suggested function parameters don't match the actual functions. You can see this from the two attached screenshots. I have also attached the PinLayout.hpp file for reference. Don't know if that will help or not.

This problem persisted after a restart, and didn't change even when the parser reread the files.

Title: Re: The 21 June 2016 build (10868) is out.
Post by: oBFusCATed on October 22, 2016, 12:30:32 am
Extract the code in a minimal samples and post an issue on the sf.net project page.
Without a minimal sample it is hard to tell what is wrong.
Title: Re: The 21 June 2016 build (10868) is out.
Post by: UberNewb on October 22, 2016, 10:49:35 pm
Nevermind, this is not a bug. It's referring to a Pin object, not a PinLayout object. The code completion is correct. The mistake is mine. I'll keep working on reproducing the other code completion failure though.