T O P I C R E V I E W |
jase439 |
Posted - Nov 13 2019 : 7:18:12 PM Not sure what VA is using as its criteria for a "recognized symbol" but I have a project where VA is underlining EVERY local and member variable as "unrecognized". Have tried flushing the cache and rebuilding symbol database to no avail. Underlining goes away after unchecking "Underline unrecognized symbols in" in Options | Underlining.
VA is 2353 under VS2019 16.3.9. I could not reproduce this in VS2017.
What's going on here?
![](https://forums.wholetomato.com/forum/uploaded/jase439/20191113191750_vax_bug_report.png)
|
29 L A T E S T R E P L I E S (Newest First) |
sean |
Posted - Feb 20 2020 : 11:04:36 PM case=97015 is fixed in build 2366. https://support.wholetomato.com/default.asp?W404#2366 |
feline |
Posted - Jan 06 2020 : 2:28:14 PM Underlining should not be related to the DPI settings, at all. It is possible you have encountered a situation where these do effect each other, but if so it's not a problem that I recognise.
For the other bug, are you talking about VA not understanding variables called "thread"? If so, this is covered by
case=141560
and is fixed in our latest version, VA 2358
http://www.wholetomato.com/downloads/default.asp
so if you are still seeing problems with this version of VA, can you explain what problem you are seeing? |
jase439 |
Posted - Jan 02 2020 : 2:38:04 PM Just wondering if the squiggle opacity/appearance in VS2019 (mentioned earlier in this thread) could be related to the DPI rendering option mentioned here:
https://forums.wholetomato.com/forum/topic.asp?TOPIC_ID=16795
Also curious if any headway has been made on a fix to this issue and/or if it's in the queue for an upcoming release. |
ChrisG |
Posted - Nov 27 2019 : 04:18:38 AM Yes, and I have responded via email. |
jase439 |
Posted - Nov 26 2019 : 1:28:57 PM Just wanted to confirm that you received the code sample and were able to reproduce the issue(s) from this thread with it. |
jase439 |
Posted - Nov 23 2019 : 3:17:41 PM quote: Originally posted by jase439
quote: Originally posted by feline Can you please sent the sample to:
On its way!
quote: Originally posted by feline What happens with the sample code when pasted in to your main solution? I am assuming that the problems with the "thread_t" variable shows up here as well?
The behavior is inconsistent/unstable for me. When I first introduced the code, it seemed fine, but then I closed the solution and reopened it and it was suddenly not fine (behaved exactly like ThreadMain plus all the member variables/local vars got the squiggly treatment. Not sure what to make of that.
I will include this in the sample I send over so you can play with it.
|
jase439 |
Posted - Nov 23 2019 : 2:59:21 PM quote: Originally posted by feline Can you please sent the sample to:
On its way!
quote: Originally posted by feline What happens with the sample code when pasted in to your main solution? I am assuming that the problems with the "thread_t" variable shows up here as well?
Yes.
I will include this in the sample I send over. |
feline |
Posted - Nov 23 2019 : 08:02:33 AM Can you please sent the sample to:
[email protected]
including this thread URL so we can easily match it up. Any sample you send will only be used to understand the underlining problem, and nothing else.
What happens with the sample code when pasted in to your main solution? I am assuming that the problems with the "thread_t" variable shows up here as well? This does suggest a problem from somewhere else, hopefully the sample will help to point us in the right direction. |
jase439 |
Posted - Nov 22 2019 : 1:07:08 PM quote: Originally posted by feline If you use Alt-Shift-G, Goto Related, on the "thread_t" type, and select "Goto Member", are you seeing the correct class members for this class listed?
I am. Everything appears to be in order.
quote: Originally posted by feline I have set up the following simple test here, and there is no VA underlining, and the context and definition fields always show something sensible for me in the three different "thread_t" type variables. Can you please try this test code and see what results you get with it?
This sample, pasted into a dummy app, produced expected results: no errant VA underlining.
quote: Originally posted by feline If you can easily produce a sample code file that has all of the symbols underlined then I would be most interested in having a look at it.
I have that sample prepared for you and it does reproduce the issues (for me at least) that I've mentioned here (in VS2019 16.3.9). Just let me know where to e-mail it (I am unable to post it here in open forum unfortunately).
Maybe you will also see the fourth issue I mentioned in passing with the VA underlining opacity ranging from very opaque to almost imperceptibly translucent in the VS2019 IDE. |
feline |
Posted - Nov 22 2019 : 07:56:17 AM If you can easily produce a sample code file that has all of the symbols underlined then I would be most interested in having a look at it. Mismatched brackets due to #ifdef blocks are not uncommon, and VA should handle these fairly well. In theory, once VA finds the start of the next method in the file our sense of matching brackets gets reset. So normally the problem only effects, at most, one function after the function with the mismatched brackets.
But even with several functions in a row, I could not get the same behaviour here.
The problem with the "thread" variable almost feels like the same problem, caused by something further up the file.
If you use Alt-Shift-G, Goto Related, on the "thread_t" type, and select "Goto Member", are you seeing the correct class members for this class listed?
I have set up the following simple test here, and there is no VA underlining, and the context and definition fields always show something sensible for me in the three different "thread_t" type variables. Can you please try this test code and see what results you get with it?
long felineTestThreadType()
{
thread_t directThreadFeline;
thread_t *pointerThreadFeline;
// testing forum thread code here, no VA underlining for Feline
thread_t *pComplex{ (thread_t *)NULL };
pComplex;
long ret{ -1 };
if (pComplex)
{
{
pComplex->Enter();
ret = !pComplex->IsFaulted() ? pComplex->GetExitCode() : -1L;
pComplex->Leave();
pComplex = NULL;
}
}
// testing simpler variables here
// still no VA underlining here
directThreadFeline.Enter();
pointerThreadFeline->Enter();
return ret;
} in case it helps, I am using the following, rather basic, "thread_t" type, to make sure that all of the symbols are known:
class thread_t
{
public:
thread_t() { }
void Enter() { }
void Leave() { }
bool IsFaulted() { return false; }
long GetExitCode() { return -1; }
};
|
jase439 |
Posted - Nov 21 2019 : 4:19:59 PM quote: Originally posted by feline I still don't know how you ended up with all of your variables being underlined as mistyped symbols though, that is strange.
It only seems to happen when the net number of closing braces > net number of opening braces. Is this something you want to investigate further (i.e. is it worthwhile to prepare a small dummy application demonstrating the problem)?
quote: Originally posted by feline Point 3, if you place the caret into one of the "thread" variables, what if anything is VA showing in its context and definition fields?
With the caret on the variable, nothing is displayed in either context/definition window. If I place the caret on the thread_t TYPE, a correct context/definition is displayed.
quote: Originally posted by feline If you press Alt-Shift-G for "Goto Related" on one of the "thread" variables, what happens?
I get an error popup, "Goto Related is not available for this text."
If I place the caret on the underlined METHOD, however, and press Alt-Shift-G, I get the following:
![](https://forums.wholetomato.com/forum/uploaded/jase439/20191121162443_vax_bug_report_8.png) |
feline |
Posted - Nov 21 2019 : 2:53:27 PM Point 1, yes, if the brackets in your code end up mismatched then this can confuse our parser. So long as we want VA to be active in, and helpful in both active and inactive code this is hard to avoid, since it requires us parsing even the #ifdef'd out code.
We try to recover from confusion with the mis-matched brackets as fast as possible, but if you are at least aware this is happening, you can keep an eye out for it.
I still don't know how you ended up with all of your variables being underlined as mistyped symbols though, that is strange.
Point 2, yes, agreed, this is not ideal. I think this is covered by:
case=30989
Point 3, if you place the caret into one of the "thread" variables, what if anything is VA showing in its context and definition fields? These are normally shown at the top of the editor window, and are where the Alt-M list appears from.
If you press Alt-Shift-G for "Goto Related" on one of the "thread" variables, what happens? VA should offer information on the "thread_t" class. But if it understands this correctly the members should not be being underlined, as they clearly are. |
jase439 |
Posted - Nov 20 2019 : 1:40:28 PM So the observation of 4 opening / 3 closing braces was very astute (they balance properly when taken the #ifdef'd clauses separately, but taken collectively together they do not).
I rejiggered the code this way:
![](https://forums.wholetomato.com/forum/uploaded/jase439/2019112013511_vax_bug_report_7.png)
...and your parser is MUCH happier with that. VA Outline now lists all the method bodies implemented in the module (although ThreadMain still shows an #endif as part of its signature - a separate issue). Curiously, if I replicate the curly brace in the #ifdef/#endif thusly:
#ifdef __linux__ static void *ThreadMain(void *data) { // replicated opening curly #else static DWORD WINAPI ThreadMain(LPVOID data) { // replicated opening curly #endif
Then ThreadMain's signature appears normally in VA Outline. Except, by doing this there's an imbalance in the "net total" curly bracing again (this time 4 opening, 3 closing) that causes VA Outline - instead of ignoring the rest of the file - to put the totality of the file inside the #else // __linux__ clause:
![](https://forums.wholetomato.com/forum/uploaded/jase439/2019112013160_vax_bug_report_7b.png)
Curiously, in this configuration, the squiggly/reference processing in the rest of the file seems to work OK. I can, of course, remedy both problems entirely by re-balancing the net curly brace equation by closing ThreadMain thusly:
#ifdef __linux__ return (void *) ret; } #else return ret; } #endif
With 4 total opening and 4 total closing braces, VA Outline behaves exactly as you might expect:
![](https://forums.wholetomato.com/forum/uploaded/jase439/20191120132016_vax_bug_report_7c.png)
...and all is well. Almost. For whatever reason, the thread->MethodXXX(�) references inside of ThreadMain itself are completely buggered and no amount of rejiggering seems to placate VA in resolving those method references. I don't have a good explanation for that.
To your last point, the underlining behavior in this file appears to be "stable" (scrolling yields consistent results - for better or for ill depending on the state of the curly brace balancing act)
It seems like there are 3 issues here:
1. VA reference tracking and VA outline both become confused when the net total of curly braces for all #ifdef/#endif code blocks are not in balance even when they are balanced in one configuration or the other.
2. VA outline automatically treats any content appearing between the closing parenthesis of the function signature and the opening curly brace as a bonafide part of the function signature. You can stick an #endif here, a comment, or any other C++ token and it will appear in the outline as part of the function signature (arguably, anything after // or /* or # up to the opening curly should be ignored). The method list (Alt+M) is not confused by this - so maybe look to what that code is doing.
3. Independently of #1 or #2, the global function ThreadMain is unable to resolve any method references of class thread_t - even when all the #ifdef'ing is removed:
![](https://forums.wholetomato.com/forum/uploaded/jase439/20191120133615_vax_bug_report_7d.png)
Something in VA understands what these symbols are, because I can Alt+G to those symbols and they all land in the correct places.
It seems as if I have concocted a particular class file that is particularly noxious to VA. I will see if I can isolate this file into a standalone dummy app that can stably reproduce the issues here. That may be more efficient than throwing screen captures back and forth over the fence. Maybe you can even include it as part of your smoke test suite ;-)
Sorry for the tome. Hope something here is helpful. |
feline |
Posted - Nov 20 2019 : 09:18:53 AM This is an interesting, and frustrating discovery. The function you have here does have mismatched curly brackets, 3 opening and 4 closing, if you ignore all of the preprocessor braches, as VA will. However, even retyping this function in full here, I am not seeing any sign of the problems here. Plus one unmatched curly bracket really should not have this much of a knock on effect on the rest of the file.
Testing here, if I copy and paste this function, so I have the same function 5 times in a row, giving me 5 unmatched brackets, one per function, I can reproduce your problem here, but only very briefly. As soon as I finish pasting in the function, local variables in the following code are underlined by VA as mismatched symbols. However after a page up / page down, or some scrolling, the underlining disappears, and VA is back to underlining correctly once more.
How stable is the underlining for you when scrolling through your code?
I am starting to wonder if instead of a single problem point in your code, you are managing to show VA many small parser problems in a row, and the total of all of these parser problems is the cause of the underlining. It would explain what we are seeing here at least.
If you have the time can you please try copying this cpp file into your dummy "Hello World" solution, and see if you get the same underlining there as well?
I think we are getting closer, but I still cannot reproduce this properly here. |
accord |
Posted - Nov 20 2019 : 07:48:47 AM Thank you, your feedback is very promising. We've already taken steps to fix this in method list, but we wanted to get feedback before trying to apply that fix for VA Outline as well.
case=97015
VA Outline is more complicated so we wanted to proceed carefully, fixing problems in method list first, to lessen the chance of breaking VA Outline in cases where it now works.
Handling ifdefs in our parser is tricky because it was designed to work with different branches. Say you set "debug" configuration but you're editing code that's ifdefs to be only used in "release" code - we want VA features to work with these kind of "inactive" code as well. (as VS calls it) |
jase439 |
Posted - Nov 19 2019 : 10:53:39 PM quote: Originally posted by accord
Do these problems occur inside method list as well? When you press alt+m, you get a searchable list somewhat similar to VA Outline
The method list dropdown does not appear to be affected here. Everything appears to be present (and parsed normally) in that list. |
accord |
Posted - Nov 19 2019 : 8:21:38 PM Do these problems occur inside method list as well? When you press alt+m, you get a searchable list somewhat similar to VA Outline.
We've made some improvements for alt+m in similar situations and we're planning to enable those for VA Outline as well at some point. |
jase439 |
Posted - Nov 19 2019 : 2:58:21 PM I also made a couple of (significant?) observations:
1. The VA parser does not like anything between the end of a function declaration and the opening curly '{'. Doing so causes VA to treat whatever is between the function declaration and the curly brace as part of the function signature. If I comment out the #endif at line 35, then VA Outline shows the signature of ThreadMain as:
ThreadMain(LPVOID data) //#endif
However, this #ifdef/#endif pair is NOT responsible for the underlining nonsense which follows in the rest of the file.
2. The #ifdef at line 50 is what is triggering all the underlining below that point to go south. If I comment out JUST this line - even though the #ifdef/#endif is unbalanced - all the errant undefined symbol squiggles below that point disappears. Moreover, VA Outline magically displays the rest of the method bodies for class thread_t.
|
jase439 |
Posted - Nov 19 2019 : 2:45:05 PM Thanks for this test snippet.
The result is precisely as you've described. Almost :)
So if I place this snippet of code just above the thread_t c'tor (as shown in my opening post), the underlining behavior can be toggled on and off by [un]commenting the __asm { directive. When uncommented, ALL that errant underlining below that point is suppressed.
BUT!
If I move the block of code to a point just above ThreadMain (the function that features that #ifdef __linux__ #else/#endif declaration that is confusing VA Outline) the errant underlining in ThreadMain (and ONLY ThreadMain) *persists* when __asm { is uncommented.
Screenies below:
WITHOUT__asm {
![](https://forums.wholetomato.com/forum/uploaded/jase439/2019111914442_vax_bug_report_6a.png)
WITH __asm {
![](https://forums.wholetomato.com/forum/uploaded/jase439/20191119144452_vax_bug_report_6b.png)
|
feline |
Posted - Nov 19 2019 : 08:26:05 AM I have seen problems where some "odd" code confuses VA before, but I don't think I have ever seen one that behaves just like this. Normally the problems stop after one, or at most two, functions after the problem code. Plus here it is only variables, not function names being underlined, which is really strange.
Let's just test, and hopefully prove that this is actually a "something up above is confusing VA's parser" problem. In one of your files where you have this problem can you please place this test code, after one of the functions that has the underlining problem:
#if 1 == 0
// Test - Uncomment this line and VA underlining of mistyped symbols below is disabled
// all VA syntax colouring below should also be disabled
//_asm {
#endif
void testingVAUnderlining()
{
// VS2019, settings:
// IDE tools menu -> Options -> Text Editor -> C/C++ -> Advanced -> Disable Database = True
// VA Options -> Underlining -> Underline unrecognized symbols using = Blue
// both instances of the symbol name are underlined in blue
nUnknownSymbolFeline = 3;
nUnknownSymbolFeline += 2;
} hopefully VA will underline "nUnknownSymbolFeline" as expected. If so, can you please uncomment the "_asm {" line. This is wrapped in the #if 1 == 0 block to make sure you can still compile and work normally with this in your code.
Does uncommenting this stop the underlining of "nUnknownSymbolFeline" and all of the variables further down the file? It should, if VA is doing what I think it is doing.
If all this works as expected, can you simply try moving this test block up your file, and see what happens? In theory once you place the uncommented "_asm {" code above the "problem" #include line and give VA a couple of moments to catch up, this should fix the problem.
I am happy to test any code files you have that trigger this problem, if sending them to me purely for testing purposes is an option. I know this isn't always an option, but if it helps you, the offer is there. |
jase439 |
Posted - Nov 18 2019 : 4:18:14 PM quote: Originally posted by feline
Honestly I don't know why the underlining looks different at different points in your file. At a guess, it is related to the setting:
IDE tools menu -> Options -> Text Editor -> C/C++ -> Formatting -> Colorize inactive code blocks in a different color
but this is just a guess.
This was my first guess also. I disabled this feature just to see if it had an impact, and it did not. I also tried changing the inactive code opacity to 100 to no effect (with regard to squiggles).
quote: Originally posted by feline
Do you have quite a lot of the #ifdef blocks in your code? This might be what is causing the problem.
A bit. This code is fairly generalized and meant to work with different platforms and compilers so there are a greater number of #ifdef blocks in this project than there are in a "typical" application-level project. Though it seems like concatenating an #endif to the end of a function declaration is definitely a bug in the parser and would certainly explain why everything that follows it has no declarative context.
I'm more concerned about the whole file being undefined than one-offs like the make_waitable_task call passing a lambda which is itself a variadic template member function - something that is very nuanced as far as C++ is concerned. |
feline |
Posted - Nov 18 2019 : 3:06:07 PM Honestly I don't know why the underlining looks different at different points in your file. At a guess, it is related to the setting:
IDE tools menu -> Options -> Text Editor -> C/C++ -> Formatting -> Colorize inactive code blocks in a different color
but this is just a guess.
Do you have quite a lot of the #ifdef blocks in your code? This might be what is causing the problem. Not the blocks themselves, but you can end up with code like:
static void *ThreadMain(void *data)
{
#ifdef __linux__
callingWithVariableParameters(1, 2,
#else
callingWithVariableParameters(3,
#endif
);
} since VA is designed to parse and be active in both the #ifdef and the #else block, so we can help you regardless of where you are editing, we are looking at and considering both blocks at the same time. If doing so introduces mismatched brackets this can cause the sort of confusion you are seeing here.
If this was happening in a commonly used header file, it might explain why the problem is showing up so widely for you. |
jase439 |
Posted - Nov 17 2019 : 12:20:49 PM Without the current line highlighted:
![](https://forums.wholetomato.com/forum/uploaded/jase439/20191117121533_vax_bug_report_4.png)
Yes, that is C++ lambda syntax (being passed to make_waitable_task)
In the first photo of this thread, you can also see some variance in the underlining opacity at line 71. The call to Trigger() looks like it's got a bold opaque underline compared others. Though none of the underline/squiggles in this screenshot are as "imperceptibly faint" as the one shown above (under jobs_queued_x).
I'll take a look at the VA outline for these files and let you know if anything jumps out at me.
UPDATE:
Yeah, the VA Outline for these CPP files looks a little goofy for me. This is what I'm typically used to seeing displayed for a class implementation file:
![](https://forums.wholetomato.com/forum/uploaded/jase439/20191117131127_vax_bug_report_5a.png)
The VA Outline for the thread_t class from the first photo looks like this:
![](https://forums.wholetomato.com/forum/uploaded/jase439/20191117131242_vax_bug_report_5b.png)
Notably absent from the outline is the section for thread_t's method implementations. Notice the #endif at the end of ThreadMain - it's almost like the parser thinks #endif is part of ThreadMain's function signature.
Here's how ThreadMain appears in code (which may provide a clue):
#ifdef __linux__ static void *ThreadMain(void *data) #else static DWORD WINAPI ThreadMain(LPVOID data) #endif { /* function body */ }
By incorporating the #endif into the function signature, the corresponding #ifdef becomes unbalanced and is probably why the remainder of this file is subsequently ignored. |
feline |
Posted - Nov 16 2019 : 11:50:13 AM In your first screen shot, for VS2019, it looks like highlighting the current line is also a factor in how the underline is being drawn. If you move the current line "out of the way", so it is not a factor, are the underlines shown the same? Or are they still shown differently?
Is this C++ Lambda syntax you are using here? I don't really recognise this syntax, so am trying to work out what to research to try and understand what is going wrong here.
It is starting to sound like a common include is confusing our parser. If so, if you look at some of your commonly used header files, and show VA Outline, is the outline correct for the file? If our parser is getting confused, this will often show up in VA Outline or the Alt-M list of methods in the current file, which can also be good methods for tracking down where the problem is starting. |
jase439 |
Posted - Nov 15 2019 : 1:11:36 PM This is a normal C++ Win32 console solution with a single MSBUILD project (vcxproj). This project does feature some more advanced C++ language constructs which might be blowing VA's mind. That said, the snippet I showed earlier is a pretty boilerplate class type and doesn't feature anything terribly mind blowing in this regard. But it's possible a header it references might contain something that is making VA angry.
A new .cpp file added to the project with a dummy function behaves more or less as you might expect. Other files in the project seem "mostly" OK but occasionally, you'll see some type references which are being reported as undefined. Another weirdness is that some of the squiggles are rendered with 100% opacity and very pronounced while others appear heavily alpha blended with the background and are very subtle. They all change color in response to a change in the VA options, so I have every reason to believe these are VA squiggles (plus squiggles are explicitly disabled in the VS options).
Here's a pic of this in VS2019:
![](https://forums.wholetomato.com/forum/uploaded/jase439/20191115131222_vax_bug_report_2.png)
In this snippet....make_waitable_task is a protected member function in a template base, and here VA is falsely angry about its "undefinedness". It gets a dark emphatic squiggle. jobs_queued_x is legitimately undefined here (the real variable name is jobs_queued and the squiggle appropriately disappears in this instance when you correct the spelling), however, the squiggle looks like it's rendered with 30% opacity.
Different visual outcome in VS2017 (below):
![](https://forums.wholetomato.com/forum/uploaded/jase439/20191115133944_vax_bug_report_3.png)
Another observation: in the snippet(s) above, m_td (a member variable of the immediate class) is not underlined. This is correct behavior. However, in the destructor of this *very same* class, VA is underlining m_td as an undefined symbol.
Scrambled eggs.
Are there any log files here that can be collected that might give some kind of clue as to what's happening behind the scenes?
|
feline |
Posted - Nov 15 2019 : 07:48:25 AM The fact that this is solution specific actually makes sense. It does not tell us where to look, but at least we know there is something in the solution settings, or the code base, that is totally confusing VA.
What programming languages does this solution use? Is it all C++, or is it a mix of C++ and other languages?
Are any of the projects other types? The default extension for a normal C++ project is ".vcxproj", but it is possible to have other project types in your solution.
If all of this seems normal, then I wonder if this is a file or solution specific problem. Can you please try opening an existing code file that is not part of your solution, the new cpp from the "Hello World" dummy program is a good test, and see what happens? If having your solution open is enough to trigger this problem in all files then you should see the underlining. If the problem is specific to files in your solution then you should not see the underlining.
One thing to watch out for here, normally VA does not underline unknown symbols in your code files until you start editing the file. This is to improve performance while just browsing your existing code. So adding a couple of blank lines and waiting a moment to see if underlining happens is a good test.
If this problem is specific to files in your solution, can you try adding a new, empty .cpp file to your solution, and see if you get a local variable underlined in a new, local function? If the problem is specific to files in your solution it may be triggered by a file you are #including in all of your files, so a new, empty file without any includes should not get the problem. |
jase439 |
Posted - Nov 14 2019 : 2:11:49 PM So this appears to be something that is unique to this particular project rather than an IDE. When I fire up a "Hello World" dummy program in VS2019, the behavior is as-expected. Specifically, it may just be a particular set of modules that are affected. |
jase439 |
Posted - Nov 14 2019 : 12:27:45 PM It does, in fact, change the color of the underlining (which is why it's blue in the above screen shot ;-)
Intellisense is disabled in Options -> Text Editor -> C/C++ -> Advanced -> Intellisense -> Disable Intellisense = True in both IDE's. I did not see the option you described under Intellisense. There is a "Disable Database" option in C/C++ -> Advanced -> Browsing/Navigation. I tried setting this to True also but to no effect.
VA in VS2017 seems to work regardless of what these options are set to (at least with respect to this feature). VA in VS2019 seems to NOT work regardless of what these options are set to (with respect to this particular feature). Actually, I take that back, bizarrely, if I *ENABLE* Intellisense, the squiggles disappear. If I *DISABLE* Intellisense the squiggles re-appear under very well-defined symbols. I even changed the color to hot pink just to confirm.
Here's another tidbit of (useful or perhaps useless) info:
In VS2019, if I ENABLE Intellisense, VA does not perform underlining. Any underlining is coming from the IDE (identified by the different line style and the color is red and not hot pink). If I leave Intellisense ENABLED but DISABLE "Squiggles", VA kicks back on (local vars and member variables all get underlined in hot pink in VA's squiggle line style).
UPDATE: I was able to get this to reproduce in VS2017 with the same settings mentioned in the preceding sentence. |
feline |
Posted - Nov 14 2019 : 10:00:52 AM Are you using the same solution and code in the two IDE's? I am just wondering if we are comparing like for like when you say that the underlining only happens in one IDE.
Just to double check, if you change the colour for:
VA Options -> Underlining -> Underline unrecognized symbols using
does this change the colour of the underlining? The fact that the underlining disappears when turning off this VA option seems conclusive, I just wanted to double check, especially since the same code should behave the same in both versions of the IDE.
By default, if the IDE is underlining unrecognized symbols in your code, which happens when the IDE's intellisense parser is active, VA won't underline. So do you know if you have disabled the IDE's intellisense parser, often done by setting:
IDE tools menu -> Options -> Text Editor -> C/C++ -> Advanced -> Disable Database = True
in either or both IDE's? If this setting is different in the two IDE's this would help to explain the different behaviour, but not why VA feels the need to underline everything. |
|
|