| T O P I C R E V I E W |
| Nox Metus |
Posted - Nov 26 2014 : 2:03:17 PM
I have a C++ project where Visual Assist consistently not working properly: all refactoring items except �Find References� are grayed out, �Find References� issues errors that symbol is not recognized, Alt+G doesn't open files from include directives, when I press Alt+G on a method definition, it doesn't go to the declaration, syntax highlight doesn't highlight all methods in �VA Outline� view.
Is there a way to tell what goes wrong with VA? Some log, error messages, some diagnostic output? Or I have to guess blind?
Btw, all built-in VisualStudio means of code navigation work properly: it opens declarations, definitions, searches references, opens include files from include directives, highlights methods properly in the object browser, etc. |
| 30 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Dec 08 2014 : 7:21:59 PM
I am glad I was finally able to help, and sorry that it took so long to get here. I still have no idea how a macro could be causing the problems you are seeing here, but as you say, its probably not worth the time and effort to try and find the problem macro.
Hopefully VA is now working reliably for you. If you have any further problems please let me know and I will do what I can to help. |
| Nox Metus |
Posted - Dec 08 2014 : 1:15:55 PM
I would like to thank you for help.
Regarding searching for a particular macro that caused the problem, it would be interesting, but I'm not sure I have enough stamina to invest more time in this issue. |
| feline |
Posted - Dec 06 2014 : 2:02:21 PM
Interesting, thank you for the update. I am sorry the instructions were not as clear as they could have been.
How much has this helped? Which problems are you still seeing?
This clearly indicates some of the problems are caused by macros that VA is having problems with. If you are able to find any macros that are confusing our parser I may be able to help you work around these problems, by making sure our parser uses a simpler version of the macro. |
| Nox Metus |
Posted - Dec 06 2014 : 12:58:37 PM
Ok, I experimented and created a key LimitMacro with a default value "NoDepthLimit". Also I set LimitMacroParsing to 0. It helped. |
| Nox Metus |
Posted - Dec 06 2014 : 12:56:07 AM
Can you comment on the instruction, since it is ambiguous:quote:
You may find that Visual Assist has problems parsing the code. You can tell Visual Assist to evaluate macros more deeply by creating the following string registry key:
HKCU\\Software\\Whole Tomato\\Visual Assist X\\LimitMacro = "NoDepthLimit"
What is a �string registry key�? It doesn't make sense, since a key doesn't have a type. It's a value that has a type. What I should create: (i) a key that has a default value "NoDepthLimit", or (ii) a value LimitMacro in Visual Assist X key of type string that is equal "NoDepthLimit"? |
| Nox Metus |
Posted - Dec 06 2014 : 12:45:41 AM
Well, a macro redefining #include is indeed too much of a stretch.
But! We do have quite some macros for class creation.
Yes, <> are also affected. If I press Alt+G on #include <vector>, VA will suggest to jump to (among some other options) vector::vector(_Myt&& _Right, const _Alloc& _Al) definition instead of just open the header file.
Let me try �to tell VA to parse macros calling macros�. |
| feline |
Posted - Dec 05 2014 : 9:51:34 PM
You are right, that VA should parse included header files, but if VA cannot understand any #include lines, cannot find any of the header files, then it won't be able to parse them, since finding them comes first. It's a theory, just not a brilliant one.
Macros is a wild guess, to be honest. If somehow a macro was used to redefine " or #include then this might explain the problem you are seeing. No idea why someone would do that though.
A common complex macro that can confuse is a macro for the class keyword, so a macro that is used to create a class, or just part of a class. But in these cases the problem is normally limited to just the macro created classes, not all code.
A more reasonable guess is something like this in one of your main header files:
#if 0
{
{
#endif
which will confuse our parser, and all code following this is also likely to be confused. The problem is that any code before the problem #include is not going to be effected, so the very first #include in a file should work at least some of the time, unless macros are used before even the first #include.
Another thought, are #include <> lines effected? I know you have said "every" #include, but your screen shot shows a #include "" line.
Have you used the setting to tell VA to parse macros calling macros? This is explained here:
http://docs.wholetomato.com/default.asp?W363 |
| Nox Metus |
Posted - Dec 05 2014 : 7:49:32 PM
I doesn't fix the problem. I would be surprised if it did, since my understanding is .h files are parsed anyway whether they are explicitly included in the project or not.
I'll try to hunt down the offensive file with the binary search.
What is a lot of macros and what is a complex macro? Where is a definite threshold? There is nothing special about macros in my project, this is for sure. |
| feline |
Posted - Dec 05 2014 : 4:21:24 PM
Can you try removing all .h files from your solution, while keeping all of the .cpp files? What happens with this set of files? Does this fix the problems?
I am guessing that one or more macros are the problem, and macros are mostly in .h files.
Do you know if your code uses a lot of complex macros? |
| Nox Metus |
Posted - Dec 05 2014 : 01:44:05 AM
quote:
Originally posted by feline
The number of files alone does not make much sense as the problem here... You said your solution has 1,778 files. This is not a massive number of files, I have a solution with 25,153 files that I use for making sure the number of files on its own is not a problem.
Well. Then there is only one possibility left: there is one very specific file or a combination of files in my solution that breaks VA parser completely. When I removed files from the solution, I got rid of this dangerous file or combination and everything started working.
quote:
Originally posted by feline
Are any, or even most of your files very large? I have a large cpp file that is 23,000 lines long, this is what I mean by a large file.
No. |
| Nox Metus |
Posted - Dec 05 2014 : 01:39:22 AM
quote:
Originally posted by feline
So you won't get any file reads for information that lives in memory. If you want to track the file reads, you will need to track them while the symbol database is being rebuilt, after pressing:
VA Options -> Performance -> Rebuild symbol databases
It's irrelevant. When processing an include directive VA MUST query for the existence of the file inside the list of include directories. These events would have been seen in the procmon trace. No events => VA doesn't consider it as an #inlude directive => it's VA parser.
quote:
Originally posted by feline
Looking at #include lines, can you please check to see if this is a solution specific problem? In a simple test project, does alt-g on a #include line ever work?
I've already mentioned it is a solution specific. Yes, it works in other solutions. Circles detected.
quote:
Originally posted by feline
If this is a solution specific problem, then is it a file specific problem?
No. I've already mentioned that #include problem and all other problems persist throughout every file. Circles detected.
quote:
Originally posted by feline
I don't know what is going on here, so all I can do is suggest tests that might give us clues.
This is fine. Only you ignore the information I have already delivered, as if you cannot believe what I have already said. This miscommunication confuses. |
| feline |
Posted - Dec 04 2014 : 6:45:34 PM
The number of files alone does not make much sense as the problem here... You said your solution has 1,778 files. This is not a massive number of files, I have a solution with 25,153 files that I use for making sure the number of files on its own is not a problem.
I have just opened this solution, it takes a while for VA to parse everything, as you would expect, but once parsing has finished alt-g on #include lines works perfectly, I have tested this in several random files with different #include lines.
Are any, or even most of your files very large? I have a large cpp file that is 23,000 lines long, this is what I mean by a large file. |
| feline |
Posted - Dec 04 2014 : 4:58:01 PM
There is no need to re-read the cpp.tpl file if it has not changed. Re-reading a file that has not changed is not very efficient. The cpp.tpl file stores C++ VA Snippets, and is used for listboxes that appear as you type, you want that information in memory if possible. Similarly, a certain amount of the VA symbol database will live in memory, possibly all of it, since your project is not that large by some standards.
So you won't get any file reads for information that lives in memory. If you want to track the file reads, you will need to track them while the symbol database is being rebuilt, after pressing:
VA Options -> Performance -> Rebuild symbol databases
Looking at #include lines, can you please check to see if this is a solution specific problem? In a simple test project, does alt-g on a #include line ever work?
If this is a solution specific problem, then is it a file specific problem? In your screen shot the first two references are both to the SDK, directories that are part of your stable include directories. This is why I asked about:
#include <stdio.h>
in the nearly empty file. Since local variables are correctly understood by VA in that nearly empty file, with the simple test function, it seems to prove there is something in every other file in your solution that is breaking our parser, something that is even breaking #include lines, or that none of the file names you have tested are understood correctly by VA.
I don't know what is going on here, so all I can do is suggest tests that might give us clues. |
| Nox Metus |
Posted - Dec 04 2014 : 4:57:58 PM
It seems like it is the amount of files that drives VA parser nuts. I removed almost all files from the project, the remaining files behave correctly. Refactoring options, find references, opening of files in include directives, etc everything works. |
| Nox Metus |
Posted - Dec 04 2014 : 3:13:45 PM
Another demonstration that Alt+G simply doesn't realize it's an include directive. Instead of trying to search the file under the cursor among known files or known directories, it suggests to find the symbol under the cursor.
|
| Nox Metus |
Posted - Dec 04 2014 : 1:00:50 PM
quote:
Originally posted by feline
The procmon trace was when Alt-g was looking things up in VA's symbol database
I don't see any searches in the symbol database in the procmon trace. I see only checks (not even reads) on whether cpp.tpl exists, which is not a symbol database, but just autotext templates.
I am going to try to analyze the log files. |
| feline |
Posted - Dec 03 2014 : 5:15:06 PM
I realise we are going in circles, but this is a very strange situation, and I am trying to make some sense of it. I have never come across a problem before where VA does not understand that a #include line is a #include line. This either suggests something before the very first #include line is breaking our parser, or VA cannot find any files, anywhere.
Alt-g is supposed to open any file VA knows how to find. It will never open a file that is not in your solution, and not in any directory that VA has been told to search. Which is why I asked the questions I asked.
To try and check for something above the very first #include line I asked about the #include line in the nearly empty file, since things do seem to work in that file. Since things work in that file, VA is capable of parsing this single file, so something must make this file different to every other file in your solution.
Alt-g is going to be relying on VA's symbol database, but since other solutions work, and the nearly empty file works, it looks unlikely that your VA symbol database is always corrupt. The procmon trace was when Alt-g was looking things up in VA's symbol database, not when VA was building the symbol database.
Please see this FAQ for details of turning on VA's logging, and locating the log files, perhaps they will offer you some useful clues:
http://www.wholetomato.com/forum/topic.asp?TOPIC_ID=5489
I am trying to help, but this is a difficult problem. Hopefully you can see why I am asking the questions I am asking now. |
| Nox Metus |
Posted - Dec 03 2014 : 1:42:26 PM
We are moving in circles.
It doesn't matter whether aaa.h is a part of my project, it works the same. Besides, Alg-G is supposed to open any header file in #include directive, not only those that you explicitly added to the project.
The fact that I told VA not to parse other files in NO WAY can be a factor. There is a file aaa.cpp, IT IS a part of the project. It HAD TO be parsed properly, but it WASN'T.
quote:
Originally posted by feline
Can you please add the line:
#include <stdio.h>
Is it so difficult to believe what I said TWO TIMES already: VA FAILS TO OPEN ANY FILES FROM ANY #include DIRECTIVES?
IT'S NOT ABOUT VA KNOWS OR DOESN'T KNOW WHERE THE FILES ARE. IT DOESN'T EVEN TRY TO LOOK AT ANY DIRECTORIES AT ALL AND CHECK FOR INCLUDE FILES. CHECK MY PROCMON LOG.
Circles, circles, circles.
I'll consult with the legal department regarding what I can share privatively.
I'll try to analyze log files myself. |
| feline |
Posted - Dec 03 2014 : 12:58:21 AM
Thank you for the details. The NMake include path is working for me, and being picked up correctly by VA in a simple test here. Are you using an absolute path, a relative path, or a path using environment variables of some form?
For the problem with the line:
#include "aaa.h"
is the file "aaa.h" actually part of your solution? If you make sure this file is not open in any of the tabs, is it listed in VA's Open File dialog, or in the IDE solution explorer pane?
You have not told VA to parse all of the other files in the current directory, so this could be a factor, since we cannot assume VA knows about this file if it is not part of the solution.
Can you please add the line:
#include <stdio.h>
to both the nearly empty test file, and one of your normal files. Given your VA about information VA should know where this file is. Does alt-g on this file name work in either file? I am assuming you don't have a file called "stdio.h" in your solution, so VA will know which file this is.
Would you be able to share file paths, and other simple details privately, via email? Log files make sense, but will contain some solution details, so if you cannot share any details then they are not a good idea. |
| Nox Metus |
Posted - Dec 02 2014 : 2:11:06 PM
I checked file system activity on pressing Alt-G in an #include directive with procmon.
It doesn't even try at all to search any directories. So the assumption that something wrong with include directory settings is wrong.
It's you parser. I bet Alt-G simply doesn't recognize this is an #include directive. |
| Nox Metus |
Posted - Dec 02 2014 : 1:58:46 PM
IDE takes its include directory settings from here:
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<ClCompile>
...
<AdditionalIncludeDirectories>...</AdditionalIncludeDirectories>
...
</ClCompile>
...
Or in GUI it is Project Property pages->Configuration Properties->NMake->Include Search Path
Though I doubt it is the right direction. VA fails to open any header file on Alt-G from any #include directive. Even those header files that don't require any include directory settings.
Consider for example a file aaa.cpp that has#include "aaa.h" aaa.h is located in the same directory. Alt-G doesn't work on this #include. For some reason Alt-O works though. |
| feline |
Posted - Dec 02 2014 : 1:24:05 PM
Sorry for not being more clear.
Can you look at the full path of the header file, the one that alt-g fails to open, and then look at your solution settings, and try to find the setting that lets the IDE work out where this file is?
Since the IDE can find the file, but VA cannot, there must be a setting somewhere VA is not finding. If you can tell me which settings VA might be having problems with, I can test them here, and we can try telling VA about the directories it does not know about, which should help. |
| Nox Metus |
Posted - Dec 02 2014 : 01:23:58 AM
- Alt-G doesn't work with include directives even in the test file.
- I have the line ending check always on.
- Context and definition don't work, even in the test file.
- VA's open file dialog lists all 1778 .cpp and .h files explicitly specified in the project file.
- Yes, as I said before, the IDE has no problem opening any files, finding symbols, references, everything. So, yes, it does show the correspondent open file item in the context menu, it can open any file in any include directive either from the context menu or from the keyboard shortcut.
quote:
Originally posted by feline
Are you able to post the full path of the header file, and also the full path of the cpp file you started in?
Sorry my English, I don't understand. What do you mean by �started in�? Anyway, I cannot publish anything without compromising my NDA.
quote:
Originally posted by feline
Probably a missing include directory setting, or possibly a setting that VA is unable to find and understand.
If I had missed an include directory setting, the IDE would have had problems as well, right? |
| feline |
Posted - Dec 01 2014 : 11:02:36 PM
I am not giving up easily on you, on this, I plan to get to the bottom of this and see if we can fix this!
OK, there is some "good" news here, just not much. The fact that alt-g is working correctly in the simple function in an otherwise empty file tells us that VA is actually attached to your IDE, and not totally disabled and broken by your main solution. I cannot imagine how a specific solution would "disable" VA, but something very strange is going on here.
Let's study the alt-g on #include lines part, this should be relatively easy to study, and try to understand.
Firstly, the problem #include lines, if you copy a couple of these lines into the nearly empty test file, do you still see the alt-g problem? Or does copying the problem line to a new file fix the problem?
I suspect you still see the problem, but if not, if the problem is file specific, then we could be looking at macros above the #include lines, invisible control characters in the file, mixed line endings in the file, or some confusing Unicode characters in the file. All long shots, but possible.
As a sanity check for this, can you make sure you have:
IDE tools menu -> Options -> Environment -> Documents -> Check for consistent line endings on load
turned On and keep an eye out for any warnings about mixed line endings in your files.
Assuming the problem is not file specific, does VA show anything helpful in its context and definition fields, normally at the top of the editor window, when you place the caret into the file name?
Making sure the header file in question is not currently open in the editor, is this file listed in VA's Open File dialog? I am just checking if it is part of the solution or not. I am assuming it is not, but lets double check.
If you right click the file name, does the IDE offer you "Open Document "file_name.h"" near the top of the context menu? If so, and you go to the file, is VA active in the file, and is the full path to the header file shown in the definition field?
Are you able to post the full path of the header file, and also the full path of the cpp file you started in? We can then compare these directories with your solution settings, to try and work out why VA does not know about this file. Probably a missing include directory setting, or possibly a setting that VA is unable to find and understand. |
| Nox Metus |
Posted - Dec 01 2014 : 1:12:01 PM
Thank you for really analyzing the case.
quote:
Originally posted by feline
You said that in the Alt-M list some functions are not coloured. Are these functions coloured in the cpp file its self, in the editor window?
They are.
quote:
Originally posted by feline
Is Alt-g working anywhere, on anything?
It is not. It works correctly in that simple case of a local variable in a single simple function inside the otherwise empty file. Inside other files of the project sometimes it jumps correctly, sometimes it jumps to a wrong context, sometimes it suggests several locations to jump to with several absolutely wrong. Also Alg+G doesn't open header files from #include directives.
quote:
Originally posted by feline
If you are seeing problems with alt-g, does rebuilding VA's symbol database make any difference?
I have a subjective feeling that it started jumping more frequently to the right locations. All other problems remain unchanged.
Rebuilding symbol databases doesn't help. |
| feline |
Posted - Nov 29 2014 : 3:14:40 PM
I was just double checking the full solution size, trying to get a handle on what is happening here. This size should not normally be a problem, the only way it might be is if your code is very heavy on templates or macros, both of which have been known to cause problems occasionally.
Even with VA not finding some header files, a local variable in a simple function in an otherwise empty file should work correctly... Log files are starting to sound the way forward, but I like to have some idea of what to look for first.
You said that in the Alt-M list some functions are not coloured. Are these functions coloured in the cpp file its self, in the editor window?
Is Alt-g working anywhere, on anything? Or does this seem to have completely stopped working since you disabled and enabled VA? If you are seeing problems with alt-g, does rebuilding VA's symbol database:
VA Options -> Performance -> Rebuild symbol databases
make any difference? |
| Nox Metus |
Posted - Nov 28 2014 : 4:07:45 PM
quote:
Originally posted by feline
Normally solution size should not matter, but just in case how many files do you have in your solution?
It is in my previous message: around 900 of .cpp and around the same amount of .h.
quote:
Originally posted by feline
If you open VA's Open File in Solution dialog (Alt-Shift-O) the title bar contains two numbers. The first number is the number of files currently listed, which changes as you filter the list. The second number is the total number of files in the list, which is normally the number of files in your solution. What is this second number?
1778.
quote:
Originally posted by feline
Ah, a makefile solution, what do you have:
Upon opening a file, parse all other unparsed files in the same directory:
VA Options -> Projects and Files -> if Solution is empty
VA Options -> Projects and Files -> if Solution is not empty
set to?
�if Solution is empty� is checked, �if Solution is not empty� unchecked. I wouldn't like to check the second option. The amount of files will be really overwhelming.
quote:
Originally posted by feline
Does turning these settings on make any difference?
No.
quote:
Originally posted by feline
Another possibility is that we are having problems understanding the include directory settings, so are missing key header files.
That would be my assumption as well. Though it worked before. This is why I asked about log files or something. VS IntelliSense obviously finds everything alright, so I assume the project settings are correct. |
| feline |
Posted - Nov 28 2014 : 1:41:28 PM
Normally solution size should not matter, but just in case how many files do you have in your solution?
If you open VA's Open File in Solution dialog (Alt-Shift-O) the title bar contains two numbers. The first number is the number of files currently listed, which changes as you filter the list. The second number is the total number of files in the list, which is normally the number of files in your solution. What is this second number?
Ah, a makefile solution, what do you have:
Upon opening a file, parse all other unparsed files in the same directory:
VA Options -> Projects and Files -> if Solution is empty
VA Options -> Projects and Files -> if Solution is not empty
set to? Does turning these settings on make any difference? I am wondering if VA is having problems locating all of the files for your solution. Another possibility is that we are having problems understanding the include directory settings, so are missing key header files. I am not quite sure how this would produce all of these problems, but at least it is something we can look into. |
| Nox Metus |
Posted - Nov 28 2014 : 02:12:20 AM
I see these problems only in my main solution.
I made an empty file and copied there your test function testFelineTopic12121LocalVar. No changes.
It is a network drive. However I just tried to copy everything to a local drive. Same thing.
What is different about my solution is it is rather big: circa 900 .cpp files and roughly the same amount of .h files, not counting external includes. Also it is a makefile solution. But it worked before. Something changed and I don't know what. |
| feline |
Posted - Nov 27 2014 : 3:48:42 PM
Are you seeing these problems in the test solution as well as your main solution, or just in your main solution?
In your main solution, can you please make a new, empty cpp file and the copy and paste the test code into it. Do you still see the problems even in this file, with just this code?
Is your main solution being opened from a local drive, a mapped drive, some form of network drive? I am looking for any clues as to what is different and confusing about your main solution. |
|
|
