Fixed "'Data' defined as a struct here but previously declared as a c…

[olegded]

…lass" warning

Fix for "'Data' defined as a struct here but previously declared as a class" shown on Mac using clang v 10.0.0 (clang-1000.11.45.5)

Description

While trying to compile and to run the prototype and the examples on Mac, I noticed the above mentioned warning (there are no other warnings/errors on Mac using clang v 10.0.0 so far).

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Executed following tests using bash:

-rwxr-xr-x  1 ...  239652 Nov 13 13:40 vsgallocator
-rwxr-xr-x  1 ...  251480 Nov 13 13:40 vsgarrays
-rwxr-xr-x  1 ...  359176 Nov 13 13:40 vsgc_interface
-rwxr-xr-x  1 ...  355040 Nov 13 13:40 vsgintrospection
-rwxr-xr-x  1 ...  191340 Nov 13 13:40 vsgmaths
-rwxr-xr-x  1 ...  224816 Nov 13 13:40 vsgmemory
-rwxr-xr-x  1 ...    8720 Nov 13 13:40 vsgnamespaces
-rwxr-xr-x  1 ...  182736 Nov 13 13:40 vsgpointer
-rwxr-xr-x  1 ...   70088 Nov 13 13:40 vsgtypes
-rwxr-xr-x  1 ...  198520 Nov 13 13:40 vsgvalues
-rwxr-xr-x  1 ...  332732 Nov 13 13:40 vsgvisitor

Test Configuration:

• Hardware: MacBook Pro
• Toolchain: cmake + MoltenVK + Xcode
• SDK: MotenVK

Checklist:

• My code follows the style guidelines of this project
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[robertosfield]

include/vsg/core/Data.h declares Data as a class, the DispatchTraversal.h header is correct.

This means the PR introduces an error. The question has to be why you are getting a warning where there shouldn't be one.

Could you codebase not be up to date? Could there be some form of namespace pollution going on?

[robertosfield]

Ahhh... tracked it down to the DispatchTraversal.cpp declaring struct for the internal Data. The confusion over which Data is clear indication that I need to change the name of this internal class. I'll fix this.

[olegded]

I was not quite sure which direction to change :-)

[robertosfield]

The CppCoreGuidlines suggests use class for objects that has some invariant property that needs to be maintained, so in this case I think class is more appropriate as we shouldn't be willy nilly changing the how this object is managed.

I have changed this internal data class to InternalData and made both the forward declare and definition to use class:

9cc2e57