You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
If the C++ ClassToMock header contains code-sections that are disabled by using the C preprocessor idiom #if 0 ... #endif, the disabled code-section causes generated ClassA::method1 code in FSeamMockData.hpp:
WORK-AROUND: Use comments instead of preprocessor to disable the code-section (comment it out).
To Reproduce
Described above.
If the disabled code-section causes problems with FSeam, compile-time errors are caused.
Expected behavior
Disabled code-section (especially with this simple-idiom that requires no knowledge of preprocessor-defines) should not lead to code in generated MockData.
The text was updated successfully, but these errors were encountered:
It is unfortunately, a naive approach that may not give the code generator the appropriate informations to decide which preprocessor condition is true or not.
The graal of this code generator would be to use a libclang and actually not have a naive python parser but something working directly with the AST, I will update the documentation and try to think how we could solve this issue in a naive way.
Describe the bug
If the C++
ClassToMock
header contains code-sections that are disabled by using the C preprocessor idiom#if 0 ... #endif
, the disabled code-section causes generatedClassA::method1
code inFSeamMockData.hpp
:WORK-AROUND: Use comments instead of preprocessor to disable the code-section (comment it out).
To Reproduce
Described above.
If the disabled code-section causes problems with FSeam, compile-time errors are caused.
Expected behavior
Disabled code-section (especially with this simple-idiom that requires no knowledge of preprocessor-defines) should not lead to code in generated MockData.
The text was updated successfully, but these errors were encountered: