| Author |
 Topic  |
|
|
tony.riviere
Ketchup Master
France
58 Posts |
 Posted - Apr 04 2018 : 10:33:29 AM
|
In your build 2231, you "Improved parsing of projects that include Google Test".
I guess that you're parsing common gtest macros like TEST, TEST_P, etc...
On our project, we're a bit crazy and we defined our own macros on top of gtest ones: TU (for Unit Test), TV (for Validation Test), ...
So VAX doesn't work anymore in the body of these tests, exactly as it was before your improvement.
Basically, our macros have the same "prototype" as the ones from gtest, they only add a prefix internally:
#define TU(test_case_name, test_name) TEST(test_case_name, UNIT_##test_name)
Is it possible to add a list of macros which should be interpreted by VAX the same as the ones from Google Test? |
|
|
feline
Whole Tomato Software
United Kingdom
19025 Posts |
Posted - Apr 04 2018 : 2:56:48 PM
|
If you make a new text file called "va_stdafx.h" and place it in the same directory as either your SLN or VCXPROJ file then VA will find and parse this file before starting to parse your solution. There is no need to add the file to your solution, and you should avoid doing this, since its simply a helper file for VA.
In this case, you may well want to add:
namespace testing
{
#define TU(cls, meth) TEST(cls, meth)
}
make sure the file ends with a blank line, and then press the button:
VA Options -> Performance -> Rebuild symbol databases
and restart the IDE. Using this file is explained here:
https://support.wholetomato.com/default.asp?W302
You will need to add a helper macro definition for each of your own macros, to help VA understand them. I have not tested this here, but I can, if you can post a simple code example showing your macros in use, and the problem you are seeing, if this does not fix it. |
zen is the art of being at one with the two'ness |
 |
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Apr 04 2018 : 4:04:59 PM
|
rather than defining your custom macros as aliases for the google test macros, consider defining them with the same bodies as the corresponding google test macros in (vaInstallDir)\misc\stdafx.h (search for case 109691 in the file)
see https://docs.wholetomato.com/default.asp?W105 for identifying the va install dir.
|
|
|
|
tony.riviere
Ketchup Master
France
58 Posts |
Posted - Apr 05 2018 : 05:03:58 AM
|
Thanks both for the quick reply. It does solve my issue.
I had also an issue where the "Show Quick Info" was turned off, I don't know why (probably me).
Problem solved.
PS: Just to make sure I understand correctly, the user-defined macros are referenced as macro (for syntax coloration) but the code behind is not interpreted by default by the VAX parser unless we duplicate the definition inside this va_stdafx.h, am I correct? |
Edited by - tony.riviere on Apr 05 2018 05:11:09 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19025 Posts |
Posted - Apr 05 2018 : 10:22:12 AM
|
It depends on what you mean  VA attempts to understand all macros that it finds in the solution and the stable include directories, but some of these are not easy to process without actually expanding them in position, and re-writing your code files in the process, which we don't do.
The macros in the va_stdafx.h file are also "user defined macros", but are checked first, before looking at the solution, and if the same macro is defined both in the va_stdafx.h file and your solution or libraries, then the definition in the va_stdafx.h file takes priority.
So the idea is to put a simple macro that VA can interpret and make sense of in the va_stdafx.h file, to take priority over a confusing macro in the solution. Normally you want a simple macro that results in the "same" code from VA's point of view, but sometimes you just want to "hide" macros, by giving them a blank body, so VA does not bother with them in the code.
Does this make sense? |
zen is the art of being at one with the two'ness |
|
|
|
tony.riviere
Ketchup Master
France
58 Posts |
Posted - Apr 06 2018 : 04:20:49 AM
|
More or less yes. I understand that it eases the parsing process without redoing all the job that the pre-processor does and without the need to support all the fancy things that Visual Studio provides (such as force include, etc...).
Does it have something related with LimitMacro / LimitMacroParsing key registry? By default, it's turn on, I guess it's also for performance optimization? |
|
|
|
feline
Whole Tomato Software
United Kingdom
19025 Posts |
Posted - Apr 06 2018 : 04:58:10 AM
|
The LimitMacro registry key setting was an earlier version of this. The problem with this is that it is a machine specific setting, but also a "global" setting, in that it applies to all solutions. The key still exists, but we don't use it to try and fix macro parsing issues these days, since it is much less flexible.
The key advantages of va_stdafx.h are that it is solution specific, and since it is not part of the solution its self, it is generally safe to check this into source control along side your solution, so it can be shared with other users who are also using VA.
Also, consider what happens with macros and #include lines when you compile your code. #include lines are expanded into the full include file, and macros are actually replaced, all through your code, at the first stage of compiling. A powerful technique, but you basically get to re-write the code files at this stage, not something VA can really do and still help you edit the file as it is |
zen is the art of being at one with the two'ness |
Edited by - feline on Apr 06 2018 05:00:03 AM |
|
|
|
tony.riviere
Ketchup Master
France
58 Posts |
Posted - Apr 06 2018 : 10:38:31 AM
|
Perfectly clear now.
Topic can be closed. |
|
|
| |
Topic |
|
|
|
Allow to define custom macros used for Google Test
