| T O P I C R E V I E W |
| bta |
Posted - Oct 25 2017 : 11:29:32 AM
Hi,
VAX seems to be converting the . into -> in too many (all?) cases.
Consider having an std::atomic<bool> instance. When I type the . it auto converts it into ->.
This is unfortunate since std::atomic does not have a -> operator
Reproduction code sample:
#include <atomic>
void foo()
{
std::atomic<bool> b;
b // as soon as you type in the . it gets changed into ->
}
I have VAX 10.9.2237.0 with VS2015 Professional.
Note that I have both Editor options 'Convert dot to -> in C/C++' and 'Convert dot to -> if operator -> is overloaded' turned on.
Unchecking the '... if overloaded' also does not resolve the issue.
Of course unchecking both is a workaround, but disables the VAX feature...
I first thought that the issue occurs as soon as the class has some operator defined, but it seems it continuously changes all . into ->
I have the same issue with this code sample:
class Test
{
public:
void foo() {}
};
void foo2()
{
Test t;
t // as soon as you type in the . it gets changed into ->
}
Needless to say that this is pretty annoying as you have to continuously correct the auto correction with the backspace key...
I full turned off the feature for now.
Looking forward for a fix!
Bart |
| 23 L A T E S T R E P L I E S (Newest First) |
| sean |
Posted - Dec 18 2017 : 7:24:33 PM
case=112232 is fixed in build 2248. |
| feline |
Posted - Nov 08 2017 : 09:52:34 AM
I have the test solution, many thanks for this. I can see now why I was not able to reproduce this here. The missing step was making an instance of the [[deprecated]] class. It turns out you don't have to type the class type, but you do need to type the class instance name. Once you have done this, the problem shows up. I have put in a bug report for this:
case=112232
Thank you for your help in tracking this down, that is a very strange bug and interaction effect. |
| bta |
Posted - Nov 08 2017 : 02:59:37 AM
I have replied to your mail and attached my solution together with reproduction instructions. |
| feline |
Posted - Nov 07 2017 : 12:32:06 PM
Do you have a test solution where you can reproduce this problem on demand? If so, is there any chance of getting a copy of the solution, to test here?
I have tried setting up a test solution here, but so far I cannot reproduce the problem here, even with several variations on the code. If you do have something I can have a look at, either reply to my script email, or submit the files via the form:
http://www.wholetomato.com/support/contact.asp
including this thread ID or URL in the description, so we can match it up. |
| bta |
Posted - Nov 07 2017 : 08:51:34 AM
I still have the issue in the newly created sln for the last release and not in last-1 release.
But related to the [[deprecated]] issue. I think it is related since I was now able to reproduce the issue a few times (but not always) in an almost empty solution.
Note that I already tried something like this before, and then it failed but maybe it did it slightly different (I can't remember exactly...)
In last -1 we definitely didn't use the [[deprecated]] construction for class declarations.
We did use it already for marking methods deprecated though...
Just add this before the myFunction():
namespace OuterNamespace
{
namespace InnerNamespace
{
template <typename LockType>
class[[deprecated]] Guard
{
};
}
}
This seems to be enough to trigger the issue in my small dummy solution.
As soon as I put the template line in comment or the [[deprecated]] in comment, then the issue is gone....
Hope you can reproduce it as well!
|
| feline |
Posted - Nov 07 2017 : 07:33:48 AM
I have just replied to the [[deprecated]] thread:
https://forums.wholetomato.com/forum/topic.asp?TOPIC_ID=14055
We have plenty of users who work with more than 70,000 code files, so the number of files should not be a problem here. Just to make sure, since the [[deprecated]] attribute is confusing VA, were you using this before, when the dot was not converted? Since we still don't have any good clues, I don't want to just dismiss this without checking.
I have just emailed you, at your forum email, with a VBScript file that will create a test solution from your source code.
Can you please try using this script to make two solutions, one from the version of your project code that has the dot to -> conversion problem, and the second version from the earlier version of the code, without the problem.
This script is simple, and it is not designed to make any form of working solution, just enough of a solution for Visual Assist to parse all of the files. The idea of this test is to have the "same" solution for the two versions of the source code, so we can tell if the changes to the solution, or to the code triggered this dot to -> bug.
It still won't tell us the problem, but it should make it easier to narrow down where to check and what to look for. |
| bta |
Posted - Nov 07 2017 : 03:48:11 AM
We are using VS2015 professional.
I took another look at two projects (latest release (having the problem) and latest release -1 (not having the problem)).
Release last has 68884 files in it and last-1 has 64149 files in it.
I trust there is no 16-bit limit (number of files) being exceeded here?
Next to that I also notice that we are starting to use the c++ attribute [[deprecated]] more often and in fact for class declarations.
I noticed a glitch in the parsing if it is used for a template class. I will be logging a separate topic for this as it seems not to cause the issue mentioned in this post.
|
| feline |
Posted - Nov 06 2017 : 2:59:46 PM
I did not expect both types of code in the same project. I wonder if this could be a factor, but you never used to have this problem, so its not as simple as the two mixed together into one project.
Which version of Visual Studio are you using? I am wondering about the menu option:
IDE File menu -> Open -> Folder...
in VS2017, since this might allow the opening of the code without the solution, to see if this makes any difference. |
| bta |
Posted - Nov 06 2017 : 12:03:02 PM
We only have 1 solution with 1 project.
Inside this project there are c++ and c++/clr files.
(Our custom build system knows how to compile the clr files because of a naming convention)
I tried removing all of these clr files from the project but it seems to issue still persists... |
| feline |
Posted - Nov 06 2017 : 06:42:31 AM
No problems with the delay, we all have other things that need to be sorted out, and a week off should always take priority 
It does seem that "something" is triggering this problem, but apart from the dot being converted, we are not finding any signs or evidence of what is going wrong here. So, perhaps something is confusing our parser so much we end up with a "corrupt" symbol database. Or perhaps VA is working as intended, but something unexpected is being picked up in the code.
Your main solution contains a mix of C++ and C++/CLR code. Are these files in separate projects, or are they mixed together into the same project? I assume they are in separate projects, but want to check this is true.
If they are in separate projects, and you have the time, can you please make sure you have:
VA Options -> Performance -> Parse all files when opening a project
turned On, and edit the solution so that it Only contains C++ projects. Now rebuild the VA symbol database via:
VA Options -> Performance -> Rebuild symbol databases
and open the pure C++ form of your solution. Once VA has finished parsing, does VA work correctly? I am wondering both about dot not being converted to ->, and the correct classes being suggested for the inner namespace. The fact that the wrong classes were being suggested might be a clue, or it might be a separate problem.
If everything works here, can you try a pure C++/CLR solution, with a full VA symbol database rebuild?
If simply parsing the code is enough to trigger this problem, then I would expect one of these two tests to show the problem. |
| bta |
Posted - Nov 06 2017 : 04:57:17 AM
sorry for the late reply, I had a week off...
In the VA View, both are showing fine. MyNewClass gets shown as a class with a public method foo. FelineDotTestStruct gets shown as a struct with the two public members...
I have been playing around a bit more: I'll explain what I did.
As it seems related to our project, I tried removing sources from the project.
In a binary fashion I removed half of the sources (by editing the vcxproj file with a text editor and re-opening the solution).
Note that I didn't let VAX clear the cache or Rebuild the symbol databases.
As soon as I removed the first half, the issue didn't happen anymore, so I tried adding more and more files back to the project in order to find out what files were causing it.
(Each time closed VS and reopened it after editing the vcxproj file).
In the end I was able to add all files again and it was still working!
I then tried editing the file again by using some other class of our own and immediately it was wrong again.
I played some more because I thought it was related to the fact that the class was in a nested namespace.
So the extra code I typed was OuterNamespace::InnerNamespace::SomeClass s;
I tried reproducing this in another smaller project, but unfortunately I failed.
When adding something from another inner namespace, things did still work: OuterNamespace::OtherInner::SomeOtherClass s;
Note that the InnerNamespace where things went wrong was not suggested at first by the code completion while OtherInner was suggested.
After typing it in completely it was nicely colored however.
Also note that later on it proposes wrong class names in that inner namespace.
Also note that if I restart VS, the first time it is always correct (so the . is kept for the MyNewClass variable).
This is also the case even if that extra code that made it fail is already in the file.
It seems that I first have to do some action that 'breaks' it...
Still didn't figure out what it is though... |
| feline |
Posted - Oct 27 2017 : 12:09:51 PM
Class specific then, now if we could just work out why.
If you show VA View, then place keyboard focus back into the editor, and now hover the mouse over first the test class, then the test struct, how does the displayed information compare? Is the information correct in both cases? Any sign of extra items, or missing items? In theory what ever is triggering this behaviour should show signs somewhere... |
| bta |
Posted - Oct 27 2017 : 03:06:51 AM
-Enums and Structs are working fine.
-No syntax coloring nor navigation bar on the top for the .who files (.who is something we invented ourselves)
-class keyword: context and definition fields are blank and Alt+G does nothing |
| feline |
Posted - Oct 26 2017 : 1:09:43 PM
I think we are making some progress here... dots are not converted for "everything", but they are for all classes. So, lets try something else. Can you please try this extended code test, and see what happens for the struct and enum items:
class MyNewClass
{
public:
void foo()
{
}
};
struct FelineDotTestStruct
{
int nFelineOne;
int nFelineTwo;
};
enum felineColourEnum { FELINE_RED, FELINE_BLUE, FELINE_GREEN };
void myFunction()
{
MyNewClass mnc;
MyNewClass* pmnc;
mnc;
pmnc;
FelineDotTestStruct felineStruct;
FelineDotTestStruct *pFelineStruct;
felineStruct;
pFelineStruct;
felineColourEnum felineEnum;
felineColourEnum *pFelineEnum;
felineEnum;
pFelineEnum;
}
I am starting to wonder if somehow this is class instance specific. I am not sure how that could happen... but lets see if it looks like a good theory first.
I don't recognise the .who file extension, is this a standard extension that the IDE or a standard tool understands how to use?
If you open a .who file in the IDE, is any syntax highlighting applied to the file?
Is VA active in the file, does VA shows its context and navigation fields at the top of the editor?
By default I would not expect VA to notice or care about the .who files, but perhaps they are a factor here.
One last random thought. In your code files, please place the caret into the keyword "class". Is anything shown in the VA context and definition fields? What, if anything, happens when you press alt-g?
On my test machine the context and definition fields are blank for the class keyword, and alt-g does nothing. But if a macro for class is somehow causing this effect, you may get a different result. |
| bta |
Posted - Oct 26 2017 : 10:22:25 AM
Both are fine: for the real int the . stays and for the pointer the . gets transformed.
Of course here the variables are of type int and not some class.
Related to the information: it is shown correct: int and pointer to int
When doing it with
class MyNewClass
{
public:
void foo()
{
}
};
void myFunction()
{
MyNewClass mnc;
MyNewClass* pmnc;
mnc;
pmnc;
}
the . is always converted to ->
VAX shows as Context and Definition:
myFunction.mnc MyNewClass mnc
and
myFunction.pmnc MyNewClass* pmnc
As related to the diff.
I compared the sln and the vcxproj files of our latest and the R-1 release.
(Note that include paths and so on are not mentioned in the project, but are completely handled outside by our custom build system)
Except from obvious difference between cpp and h files which got added or removed or moved, I only noticed 1 obvious difference.
That is, that in the latest project we now include .who files which contain some proprietary textual info about the owners of that part of the code base.
We had those files also in the older release, but they were not included in the project.
The content looks a bit like:
# Describes the owner of this package
owner[] = XXX
# export level
experts[] = XXX ; YYY ;
# more info here
I tried including such a file in the R-1 project, but things still worked (also restarted VS just to be sure).
Another thing I noticed when looking in the sln files, is that all of our projects use the same GUID (Project line).
Apparently our sln and vcxproj files get generated like this by our build tool.
This has been like that for ages though...
|
| feline |
Posted - Oct 26 2017 : 09:31:26 AM
On the code side, can you please try the following, randomly named, and simple test:
void felineRandomNameSimpleTestjehrker()
{
int nLocalNormalFelineLKJklj;
int *pLocalNormalslkjlksd;
nLocalNormalFelineLKJklj;
pLocalNormalslkjlksd;
}
if you type a dot after the variable instances, what happens? The dot should be left alone on the n variable, and converted to -> on the p variable.
Regardless of what happens, when you place the caret into the variable names, is the correct information shown in the VA context and definition fields? One should show as a pointer, and one should not.
Is diffing the before and after makefile / VCXPROJ / SLN file an option? Since this happens everywhere, I am wondering if the include directories have changed. Perhaps an extra library is now being parsed, or a different version of an existing library? |
| bta |
Posted - Oct 26 2017 : 07:49:18 AM
-We are working with a Makefile project which contains c++ and c++/clr files. No compiler options are specified in the visual studio project.
A custom build system is used to build the project.
-The solution only has 1 project
-I did not find any "va_stdafx.h" header
The project for our release-1 which does not have the issue has exactly the same working: c++ and c++/clr files, solution has only 1 project.
|
| feline |
Posted - Oct 26 2017 : 07:38:42 AM
OK, let's go back to basics.
What programming language are you working in? C, C++, C++ CLR? Does your solution contain code in more than one programming language?
Do you have more than one project in your solution? I am wondering if somehow this could be project specific.
Can you please look for a file called "va_stdafx.h" in the same directory as your SLN or any VCXPROJ files? This file is used to give solution specific help to VA's parser, and is not added to the solution. So, if someone has added such a file, it would explain why this is solution specific and happens in all files. |
| bta |
Posted - Oct 26 2017 : 07:31:57 AM
another cross posting.
I tried it in both .cpp and .h files
Both did not have any includes at all...
Both had the issue |
| bta |
Posted - Oct 26 2017 : 07:29:59 AM
Related to your questions: I tried unchecking the options one by one and the . only is kept if both checkboxes are turned off.
When pressing the Atl+G, I get directly to the same file and position as the one you are mentioning.
Also note that it happens with any class. So I tried out a class which definitely does not exist: MyTotallyNewClassName the same thing is still happening (I can't imagine a second definition for that).
But apparently only in that Solution.
Note that a colleague has the same thing in his checkout of that solution on a different machine.
So it definitely has to do with the code in the solution somehow... |
| feline |
Posted - Oct 26 2017 : 07:23:53 AM
Cross posting.
When you make a completely new file, are you trying .h, .cpp or both?
Are you placing any #include lines into the new file?
I am wondering where the trigger is coming from, and how it is being picked up in a new, default file. |
| bta |
Posted - Oct 26 2017 : 07:21:05 AM
I just tried the same sample code in a newly created Empty c++ project and there the . is kept.
So it seems something is triggering it in my other project.
I tried clearing and rebuilding the VAX symbols but that doesn't seem to help.
I tried the same code in the solution of a different release of my project and there it nicely keeps the .
I played around in the solution that has the issue and tried putting the code in different cpp files, including a completely new cpp file and there it always converts the . to ->
Bart |
| feline |
Posted - Oct 26 2017 : 07:20:19 AM
This makes very little sense at all.
Can you please try turning off:
VA Options -> Editor -> Convert dot to -> in C/C++
Convert dot to -> if operator -> is overloaded
first just the overloaded setting, and then all convert dot to ->, and see if / when this behaviour changes?
Can you please try making a new, default C++ project and see if you still get the same problem and behaviour there? I am wondering if this is somehow file or solution specific, which this will help to test. |
|
|
