Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 Code Inspection - Out of Source Headers

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
Zadrim Posted - Oct 05 2017 : 11:13:45 AM
[EDIT] Changed title to reflect the actual issue.

Original Post:

I recently updated from version 2223 to 2237 and found that Code inspection no longer works with classes that contain export macros or derive from classes with export macros.

We use an export macro similar to: (Generated via standard CMake calls)
#define MY_EXPORT_MACRO __declspec(dllexport)

Classes are define in *.hpp files and similar to the following:
class MY_EXPORT_MACRO MyClass : public SomeNameSpace::SomeOtherClass
{
...
}

Code Inspection does not find issues contained in MyClass. This was tested by checking for pointers equal to 0 and missing override keywords intentionally placed in the class. Code inspection also does not work when the base classes uses the macro but the derived classes do not.

I am able to tell that the file is being parsed because the following segment of code is parsed and the missing override is found correctly when outside the class. However when the following segment is nested with the class the missing override is not found.

class A
{
virtual void foo() {}
};

class B : public A
{
void foo() {}
};

UPDATE:

The header that defines the export macro is generated by CMake and is placed in the Build directory. The Build directory is listed as an additional include directory. Even when the header file is added to the project the issue still exists.

However if the file is moved to be in the source directory, and included in the project file, then Code Inspection works as expected. So the issue seems to be with parsing files that are in directories that are not part of the source build.
12   L A T E S T    R E P L I E S    (Newest First)
sean Posted - Nov 10 2017 : 12:12:40 AM
case=111596 is fixed in build 2238
feline Posted - Oct 09 2017 : 5:09:32 PM
Thank you for the clear description, I have now set up a small simple test solution, using the same basic structure as you have, and I have reproduced the change in VA behaviour. In VA 2223 Code Inspection of the header files is picking up a simple issue inside the class, but in VA 2237 issues inside the header file are no longer picked up.

I am fairly sure the include directory checking for header files has to have changed here, since I set up my test case to specifically test this. Thank you for your patience and help with pinning this down:

case=111596
Zadrim Posted - Oct 09 2017 : 09:23:34 AM
Some background info that may help you reproduce the issue:

Our solution has many projects 50+ within it. Most things are dynamically linked.

We use CMake to generate the solution along with a series of header files that are macro defines such as

# ifdef my_EXPORTS
/* We are building this library */
# define MY_EXPORT __declspec(dllexport)
# else
/* We are using this library */
# define MY_EXPORT __declspec(dllimport)
# endif

CMake will place these header files into Build directory, but the path to the file is added to project so that the compiler will find the headers that CMake generates.

Within individual projects we define classes that we want to export using a statement similar to the following:
class MY_EXPORT MyExampleClass {}

Code Inspection fails within MyExampleClass (only in header though) and any derived classes of MyExampleClass (again on in the header).

I am sorry that I don't have a smaller working example to show you.
Zadrim Posted - Oct 09 2017 : 09:11:33 AM
Added the above line twice to my *.hpp files. Once in the global space and once in a class with an external macro. I ran this test with two different build of Visual Assist with no changes in any source files or project (The only changes between the two tests were changing the build version of VA)

With build 2223 both lines (void simpleNoParamTest(void);) were identified correctly. Both within the class and outside the class.

With build 2237 only the in the global space was identified. The function declaration within the class with macro defined a different file was not identified by Code Inspection.


About the search function: I believe my coworker was talking about the Find Symbol dialog, I will have to verify that and get back to you.

feline Posted - Oct 06 2017 : 3:13:05 PM
As a quick sanity check, where you have a .hpp file and code inspection is not picking up what you expect, can you please try adding the simple test line:

void simpleNoParamTest(void);

to the header file, and see if code inspection is picking up that the void parameter is redundant? I just want to make sure that code inspection is behaving as expected at least some fo the time in your code.
feline Posted - Oct 06 2017 : 2:13:36 PM
I have confirmed that something has changed in how Code Inspection is working, but so far I have not been able to reproduce your problem, but I am still looking into this and working on this.

What do you mean by the search function? Are you talking about VA's Find Symbol dialog? Alt-g? Code Inspection changes should not effect any VA symbol lookups, so this is an interesting discovery, and suggests a second change may also be at work here.
Zadrim Posted - Oct 06 2017 : 11:23:36 AM
My coworkers and I have reverted back to 2223 and Code Inspection is working for us in that version. We have concluded it broke with version 2231.

A coworker also noted that the search function failed to find variables in header files under the same conditions Code Inspection fails on. So the problem does not appear to be only with Code Inspection.
Zadrim Posted - Oct 05 2017 : 5:37:25 PM
I tried this with multiple *.hpp files and they all have nothing listed under User Includes (there are some things listed under System Includes). The header files has a mix of standard includes, 3rd party library includes, includes to other projects, and includes to files within the same directory.
feline Posted - Oct 05 2017 : 5:25:32 PM
Does the .hpp file have any #includes in it? I am not sure why no directories are logged, but this could make sense if there are no #include lines to resolve.
Zadrim Posted - Oct 05 2017 : 4:54:04 PM
Here are the results after enabling logging:

When I open a *.cpp file, I see all the expect paths listed in the VaCodeInspections.log file under the User Includes: section. Code Inspection is working as intended.

When I open a *.hpp file, the VaCodeInspections.log have no paths listed under the User Includes: section. Code Inspection is not working then.

As for the second thought, the file does exist. I am able to navigate to it using Visual Assist to view content and using Windows Explorer to locate it.
feline Posted - Oct 05 2017 : 3:32:39 PM
It sounds like something has been broken in how code inspection is picking up the include directories to search. Can you please use Windows Explorer to open your %TEMP% directory, and delete as many of the files and folders as possible. This will simply make it easier to find the log file.

Open the IDE, make sure all of the code files are closed, and then turn on the setting:

VA Options -> Performance -> Enable logging

now open one of the code files where you are seeing problems with Code Inspection not working correctly. Give code inspection a few seconds to scan the file, then close the IDE. You should now have the file:

%TEMP%\VaCodeInspections.log

if you open this file in a text editor, does it contain the path to the build directory that seems to being missed?

A second thought, when you are seeing this problem with the file in the build directory, does this file actually exist? It won't help if VA is searching the build directory correctly if CMake has not yet created the header file that contains the macro definitions. But if this was happening, I don't see why changing VA version would have an effect.
Zadrim Posted - Oct 05 2017 : 2:44:03 PM
This issue also happens when using Qt and having classes with use the Q_OBJECT macro. Any issues that Code Inspection should identify following the Q_OBJECT, are not found.

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000