| Author |
 Topic  |
|
|
SvenR
Tomato Guru
110 Posts |
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
 Posted - Jun 25 2014 : 5:12:11 PM
|
I am seeing the same problem here. Thank you for the clear description.
case=19560 |
 |
|
|
SvenR
Tomato Guru
110 Posts |
Posted - Nov 14 2018 : 08:18:47 AM
|
| _M_X64 is still not shown in the suggestion list when typing _M_ :( |
Windows 11 x64, VS 2022, VaX 10.9.2530 |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 14 2018 : 11:31:22 AM
|
This is still in our list of things to fix, and has not been done yet, but we are still aware of it. For now, if you don't mind using a work around, I have a fix for this.
First create a new, empty text file called "va_stdafx.h" and place it in the same directory as your .SLN file for the current solution. Edit this file and add the line:
#define _M_X64
making sure that the file ends with a blank line, and then save the file. VA automatically looks for this file when rebuilding its symbol database, so the file is not part of the solution, and won't have any effect on the solution, but it is used to help tell our parser things we need it to know.
To get the file picked up, press the button:
VA Options -> Performance -> Rebuild symbol databases
and restart your IDE. This should only take a couple of minutes, depending on the size of your solution.
You can add any other built in Microsoft specific macros that you use to the file in the same manor, and these will now be known symbols for VA. |
zen is the art of being at one with the two'ness |
|
|
|
SvenR
Tomato Guru
110 Posts |
Posted - Nov 29 2018 : 04:14:58 AM
|
That works, but unfortunately it colors _M_X64 different than the other specifiers. Even if I add
#define _M_IX86
#define _M_X64
to va_stdafx.h.
This case was opened more than four years ago. It is really so difficult and time consuming to add _M_X64 and some other new specifiers to VA's internal symbol database? I would think that _M_X64 is much more used today than _M_ALPHA, _M_MPPC, _M_MRX000 or _M_PPC. |
Windows 11 x64, VS 2022, VaX 10.9.2530 |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 30 2018 : 09:52:31 AM
|
Which other specifiers are you talking about? The ones that are being coloured differently to _M_X64? I would expect either no colouring or consistent colouring here.
Yes, this is an old bug, but it is also a fairly minor one, very few of our users are noticing or commenting on this, so it is not very high priority. Since we only have so many resources we need to focus and prioritise somehow. |
zen is the art of being at one with the two'ness |
|
|
|
SvenR
Tomato Guru
110 Posts |
Posted - Dec 01 2018 : 02:45:29 AM
|
For example _M_ARM or _M_ARM64. _M_X64 was introduced a decade ago and I assume, that VA's internal database for predefined macros was not updated since. So I posted the predefined macro list. In the meantime the link was updated: https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=vs-2017
It surely is a minor bug, but it bothers me every time. And I'm sure it can be fixed in two minutes (searching for _M_ALPHA and add _M_X64 to this list).
As a software developer I totally understand that there are different priorities for implementing new features or feature request, but the fixing of reproducible bugs should always have the highest priority. Especially, if your customers pay a maintenance fee. |
Windows 11 x64, VS 2022, VaX 10.9.2530 |
Edited by - SvenR on Dec 01 2018 08:09:33 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Dec 02 2018 : 08:32:53 AM
|
Apologies, I was not clear. You are talking as if some of these macros are coloured differently for you. But this is not what I am seeing here. I have ended up with the simple test code:
#if defined(_M_IX86) || defined(_M_X64) || defined(_M_ALPHA) || defined(_M_MPPC) || defined(_M_MRX000) || defined(_M_PPC) || defined(_MSC_FULL_VER) || defined(_MSC_BUILD) || defined(__CLR_VER)
#endif
to check for this, but all of these macros have the same lack of coloring for me. VA does not recognise any of them. I agree, if VA was recognising and colouring some of these and not the others then simply adding the missing ones to the list should be quick and simple. But there is no sign of any such colouring / list.
Adding these to a "va_stdafx.h" file should fix this, and it is also easy to extend if you come across any other macros that need to be added to the list.
Just to make sure I am not missing something obvious, I have tried the same code in a .cpp file in VS2017 on a clean install of VA, where VA has never been installed before, so this is all defaults. Still no colouring for any of these macros.
Assuming I understand correctly, and some of these are coloured differently for you, can you please place the caret into one of the ones that is coloured and look and see if VA shows anything in its context and definition fields? These fields are blank for me for all of these macros. |
zen is the art of being at one with the two'ness |
|
|
|
SvenR
Tomato Guru
110 Posts |
Posted - Dec 03 2018 : 07:05:26 AM
|
If I type _M_ I get this list:
After adding _M_X64 and _M_IX86 to va_stdafx.h _M_X64 and _M_IX86 are colored differently:
Now _M_X64 is shown in the suggestion list, but it is also shown in a different color here:
So where do _M_ALPHA, _M_MRX000, _M_PPC and _M_MPPC come from? It seems that these specifiers are part of VA's internal symbol database and not part of the Windows headers. |
Windows 11 x64, VS 2022, VaX 10.9.2530 |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Dec 03 2018 : 2:25:50 PM
|
This is odd, and I am getting slightly different results here.
I am seeing the colouring in the listbox, so yes, this does suggest that these are known to VA somehow. But I am not getting any colouring in the editor. I have been checking the editor only so far, and since I never see any colouring there, I assumed VA has no knowledge of these macros. Looks like it is more complex than that.
In your colour settings, what do these colours represent? Normally purple is the colour for enums and macros, but you have two quite different shades of purple going on here, as if two different colours are being used. Is the colour in your listbox the colour set for keywords and class names? |
zen is the art of being at one with the two'ness |
|
|
|
SvenR
Tomato Guru
110 Posts |
Posted - Dec 04 2018 : 03:18:44 AM
|
I'm using the following colors:
It seems that the different color for M_X64 in the editor is caused by the platform configuration. If the x64 target is selected, _M_X64 is colored as macro. Otherwise it is colored as normal text (Navy Blue on my system).
The same for _X_IX86 if the Win32 target is selected:
So this it's not an issue with VA, the default IDE's colorization works identically. It has nothing to do with adding _M_X64 to va_stdafx.h.
I have searched VA's extension directory for _M_ALPHA and found it and the other ones in Misc\cpp.va. After adding
:_M_X64� �9����
:_M_ARM� �9����
:_M_ARM64� �9����
these specifiers are also shown in the suggestion list:
It would be nice if you can add these lines to the default cpp.va. Or is it possible to use a user defined cpp.va in addition to the default cpp.va in the extension directory? |
Windows 11 x64, VS 2022, VaX 10.9.2530 |
Edited by - SvenR on Dec 04 2018 03:20:34 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Dec 04 2018 : 12:59:24 PM
|
I found the same file while trying to work out what is going on here. It's not a file I recall, but what it's doing is clear enough. I have put in a feature request to add the missing macros to this file:
case=132663
Apologies for getting side tracked with the colouring in the editor, it left me going in the wrong direction. |
zen is the art of being at one with the two'ness |
|
|
|
SvenR
Tomato Guru
110 Posts |
Posted - Dec 05 2018 : 12:06:34 PM
|
| Thanks. |
Windows 11 x64, VS 2022, VaX 10.9.2530 |
|
|
| |
Topic |
|
_M_X64 and #pragma warning(suppress:)
