| T O P I C R E V I E W |
| beylevem |
Posted - Dec 04 2008 : 10:33:25 AM
Hi Feline:
This is a continuation of topic 7979, but I thought I would start a new thread, since the original topic of that thread was not related to macro parsing.
On Nov 28, you wrote
====================
Unfortunately there is no progress to report on this. It is down as a high priority bug, but macro's are a complex subject.
It is "easy" for the compiler, since the pre-processor just expands all of them. Unfortunately VA does not have that luxury. Before you suggest doing so, #ifdef statements where VA does not know which version is active rather complicate matters.
Sometimes it is possible to help VA by adding dummy helper macros to VA's StdAfx.h file, showing how certain common macro's are expanded.
http://docs.wholetomato.com?W302
http://docs.wholetomato.com?W310
==================
1) I was asking specifically about case 729 which has to do with macro parsing when ## is used
2) Further up in that thread (Jul 16), I asked specific questions about the current behavior of the macro parsing. I don't believe that you have answered those questions, but if you have, please feel free to point me to the relevant responses
3) I understand the issues with multiple definitions for macros inside #ifdef, since VAX cannot figure out which branch is active without reference to other files. However, VAX does *something*. As best I can figure out, it uses the first definition that it finds. What is confusing is that when one clicks on the macro name where it is being used, the line at the top of the edit window which shows variable definitions shows a different and subsequent definition.
When I have multiple definitions for macros, they are all in the same source file, so consistent, predictable and documented behavior by VAX should be possible.
4) As I have mentioned elsewhere (Topic 7215), VAX forgets macro definitions. It thinks the macro invocations are function calls. The only way that I have found to fix this problem is to use the "Rebuild Symbol Databases" button, which requires closing and reopening devenv.
If we can start out by defining expected behavior, it would help both with using the current capabilities, and it would also make it easier to identify and document cases where there behavior deviates from the rules. |
| 16 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Feb 12 2009 : 7:30:17 PM
Some changes have been made internally that might help with this. They should be included the next build of VA, so hopefully that will be more reliable.
Related to:
case=23013 |
| feline |
Posted - Feb 12 2009 : 10:59:28 AM
I will ask internally and see if anyone has any ideas on what to try. I understand that you don't have the time to run to many tests here.
At least reparsing seems more effective in 1715, this is one small piece of good news. |
| beylevem |
Posted - Feb 11 2009 : 12:49:41 PM
Since the problem can be made to go away by forcing reparsing/rebuilding the database, I'm not sure how reproducible it will be if I try what you suggest, and I have very little appetite to invest time for a maybe outcome.
With build 1715, reparse file seems to work better. I can generally make the problem go away by reparsing the file in which the macros are declared, followed by reparsing the file in which the macros are used. What is really confusing is that different macros appear undefined in different client files. Otherwise, I might have thought that it was some kind of problem with the sequence in which VA scanned files.
At this point, all I intend to do is monitor the behavior for further clues.
|
| feline |
Posted - Feb 06 2009 : 2:14:14 PM
If you copy just these few files, and place them into a new test project, do you still see the basic problem, where the macro is coloured correctly in one file but not in another file?
I am trying to separate the macro definitions, which sound slightly complex, and usage, from the rest of your solution. |
| beylevem |
Posted - Feb 05 2009 : 09:54:15 AM
I appreciate the suggestion, but the macro is defined in only one file. It is defined multiple times within the file in a #if defined() #elif defined() structure, but again, I have taken care to ensure that the first definition is the one that VA should use.
In checking up some more on this, I found some more interesting/frustrating facts. I did a global search one one macro, and browsed through the files using the macro. I found at least two macros where in one client file, the macro is interpreted correctly, while in another file, it is not. If I run a VA Find references on the symbol, it is listed in the file(s) where it is recognized, and is missing from the file where it is not recognized. In the instance that I looked at the situation was exactly reversed for a different macro in terms of in which file it was recognized. The client files consist of a series of macro invocations. There doesn't seem to be a pattern to what is missed - sometimes it is the first macro, sometimes it is not. Another weird thing this time, is that the variables being declared by the macro are known to VA. If I click on the variable name, either in the macro whwrw it is defined, or in code where it is used, VA shows the correct variable definition - which implies that VA used the macro at some point to expand the code and create the definition. But the macro is currently displaying as a function in that file (but correctly as a macro in another)
Just for reference, my current setup is given below (but this problem has manifested for a long time, going back to when I used VS6:
VA_X.dll file version 10.5.1715.0 built 2009.01.25
Licensed to:
DevEnv.exe version 9.0.30729.1
msenv.dll version 9.0.30729.1
Font: Consolas 15(Pixels)
Comctl32.dll version 6.10.6001.18000
Windows Vista 6.0 Build 6001 Service Pack 1
2 processors
Platform: Custom
Stable Includes:
Other Includes:
Stable Source Directories:
|
| feline |
Posted - Feb 05 2009 : 09:25:46 AM
Can you do an IDE Find in Files for the macro name please, and see what you get?
I am wondering if VA might be seeing this symbol name in another context, perhaps as a function, somewhere in your code, and if this is triggering the problem.
Something must be triggering this problem, and a different definition sounds like it could possibly cause problems. |
| beylevem |
Posted - Feb 04 2009 : 5:35:46 PM
The macros are defined in a separate file, which is #included at the top. The frustrating thing is that this problem manifests when neither the macro definition file nor the macro client/user file has been changed - i.e. VA "forgets" the macro definition.
I had the problem manifest again after my last posting. In that instance, switching to the file that contains the macro definitions, and hitting reparse file fixed the problem. BUt once again, this a a file that hadn't changed... |
| feline |
Posted - Feb 04 2009 : 5:17:05 PM
I am really not sure what to make of this.
The initial problem, everything below the macro that VA thinks is a function is underlined, this makes sense. This happens when you get a cascade error, something just confuses our parser, and everything following it is seen as a problem.
But why this strange reparsing behaviour.
Where is the macro defined? If VA needed to re-parse the macro definition to make sense of the code, then you would have to reparse that file, or perhaps a file that included it, to clear up the problem. |
| beylevem |
Posted - Jan 31 2009 : 11:56:17 AM
A follow-up to the question about whether VA thinks the macros are functions. The behavior manifested again this morning. I did the following:
1) Turned underlining of spelling errors / mistyped symbols on
The macro that looked like a function was not underlined. The variable that was being defined by the macro was underlined.
There were macros below that, that were colored like macros. However, clicking on the variable that they were defining showed nothing in the status bar at the top, and going to the cpp file where the variables are used showed the variables underlined. I.e. VAX had lost everything below the point where it thought it had a function instead of a macro. (It was almost like it really thought the whole block of code was a function definition)
2) Clicked on reparse file numerous times with no effect
3) Added a space to the bottom of the file to force the file to be marked as changed. Hit reparse file - no effect
4) switched to another file and hit reparse on that file
5) switched back to the file and hit reparse.
Somewhere round here, I saw the status line at the bottom flash with a message about reparsing, and the problem went away... |
| support |
Posted - Jan 27 2009 : 9:15:55 PM
case=21352 is fixed in build 1715 |
| beylevem |
Posted - Dec 23 2008 : 12:14:37 PM
I'm pretty sure that VA is guessing when it treats it as a function. Almost all of my macros have arguments. I have underlining turned off - I'll temporarily turn it back on. I am not currently noticing a problem. As soon as I do, I'll report back. |
| feline |
Posted - Dec 23 2008 : 11:29:25 AM
The macro's that are coloured like functions, do they look like functions? For example:
BEGIN_NAMESPACE
FIND_MAX(2, 3)
assume both of these are macros. One looks like a function (it has brackets and parameters) and one does not. If VA's colouring code no longer understands what the macro is, it is probably going to "guess", and colour things that look like functions as functions.
Do you have:
VA Options -> Advanced -> Underlines -> Underline mistyped symbols using
turned on or off? If this is off can you please turn it on. This will not start underlining until you make an edit in the current file, so if you add an invalid variable after a problem macro, e.g.:
kjhfkjdsf = 2;
are the unknown macro's underlined?
I am trying to get a sense of the "scale" of the problem at the moment. If VA does not know what the macro's are, then it should underline then. |
| beylevem |
Posted - Dec 23 2008 : 11:10:55 AM
Hi Feline:
The macros are colored as if they were functions. Alt-G (I normally use the red arrow) is completely broken.
If I need to work on a second project, I typically open a second instance of VS2008, but occasionally I will switch solutions within the IDE.
I have been trying to see a pattern to the behavior as well, but it is difficult, because the problem most often manifests in files that I am not actively working on, so I don't immediately notice that there is a problem.
One clue that I am trying to use is the fact that the only way to fix the problem appears to be to rebuild the database. I'm trying to understand what part of the chain is broken, and why "reparse current file" appears not to work. I have tried reparsing both the file in which the macros are defined and the file in which the macros are invoked. |
| feline |
Posted - Dec 18 2008 : 12:54:33 PM
Apologies for the delay in getting back to you about this, I have been busy with the new build of VA.
I see the link to that other thread now.
Once the problems start to show up are these macro's still coloured as macro's?
Does alt-g do something useful?
VA should not get confused like this and just forget symbols.
Do you often work with more than one IDE open?
Do you swap between multiple solutions, or mainly just work on a single solution?
I am looking for any form of clue as to what might trigger this problem. |
| beylevem |
Posted - Dec 09 2008 : 12:12:03 PM
Hi Feline:
Sorry for the delayed response. I forgot to subscribe to the topic, so I didn't get notified when you posted your response.
wrt item 2, I found one source of my confusion. Without using any macros, if I declare
double MyVar() {}
void MyVar(double) {}
and then use the function
double r = MyVar();
When I click on MyVar, the status line at the top shows "void MyVar(double){...}" I.e. VAX shows the *last* definition (the others are available if one uses the dropdown). This is unrelated to macros, but causes confusion when one wraps the declaration in a macro:
#define DEFINE_VAR(var, varType) \varType var() {} \void var(varType) {}
DEFINE_VAR(MyVar, double)
The fog is starting to lift. Knowing that case 21352 is a problem, and understanding that it is the first macro definition, but the last function definition that is displayed helps.
wrt item 4, yes, I did mean that thread. My problems related to this manifest in two ways:
1) If I make changes to macro definitions, very often I cannot get VAX to parse those changes. Clicking the "reparse current file" button does not appear to do anything. If I want to see the effect of the changes, I have to rebuild the database.
2) VAX appears to "forget" macro definitions. These are definitions which have been stable for an extended period. The symptom of this is that if I click on the macro name at the point of usage, VAX shows context information as if the macro were a function definition, not a macro. Again, reparsing the file that contains the macro definition does not help. The only way to correct the problem is to rebuild the database.
It is not just the macro itself that is unknown, but the variables/functions that the macro is declaring. The effect of this is that the name completion, etc stops working.
|
| feline |
Posted - Dec 04 2008 : 12:06:26 PM
Point 1, case=729 is for ## in macro's. This is a fairly well defined problem.
My concern here is the things I have seen people do with macro's that use ##. I have memories of using this to generate class names, which when it involves template classes and inheritance, gets rather nasty.
It would be good to see this fixed for basic cases though, I totally agree. It is down as urgent, and it would make my life easier if it was fixed 
Point 2, the honest answer is that I do not know exactly how VA handles macro's. It seems to depend to a degree on the code involved. I know I tried to get to the bottom of this myself once, but the user who was reporting macro problems at the time had a code file that was several thousand lines of solid macro's 
In general I do expect VA to use the first macro that it finds.
One complicating factor is the special case handling of macro's that just wrap functions, e.g. LoadAccelerators(), which just calls the Unicode or non unicode function according to the settings.
Point 3, VA using one macro definition but showing another, I was not aware of this. I have put in a bug report for this, since it is clearly not helping:
case=21352
I agree that predictable behaviour for macro's should be achievable. In my experience people rarely use macro's in isolation, they are often doing other "complex" things at the same time, which complicates the picture.
Point 4, do you really mean this thread:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=7215
scan reading the thread, I remember taking that picture at the bottom. From memory the problem here was the Unicode parameter, and nothing to do with macro's. |
|
|
