nanopb has a habit of generating macros which end with an escaped empty line (for example for messages which are empty). They look like this:
#define some_msg_t_FIELDLIST(X, a) \
#define some_msg_t_CALLBACK NULL
This caused CMock to strip all of the newlines after the backslash instead of only one, which the backslash was escaping.
This in turn caused both the macros to be in one line, causing a compile error in the generated mock.
This reverts commit 7fbeb40965.
This causes compilation warnings / errors when a project uses
-Wmissing-prototypes compilation flags for safety reasons:
.../test/mocks/mock_logMessages.c:685:6: warning: no previous prototype for ‘CMockExpectParameters_log_message’ [-Wmissing-prototypes]
685 | void CMockExpectParameters_log_message(CMOCK_log_message_CALL_INSTANCE* cmock_call_instance, const char* logMessage, int messageID, severity_t severityIn)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
etc.
Signed-off-by: André Draszik <git@andred.net>
Compiling a source base / test with Wsign-conversion enabled, gives
the following warning:
build/test/mocks/mock_logMessages.c: In function ‘countLogMessages’:
build/test/mocks/mock_logMessages.c:749:26: warning: conversion to ‘size_t’ {aka ‘long unsigned int’} from ‘int’ may change the sign of the result [-Wsign-conversion]
749 | cmock_call_instance->ReturnThruPtr_fileIn_Size);
| ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
The ReturnThruPtr_XXX_Size is used as argument to a call to memcpy(),
which expects size_t (unsigned) for a good reason. The size leading
to this call is being determined using sizeof(), so there appears
no reason to ever convert this to (signed) int.
Stop converting size_t to int, and thereby fix the compiler
warning.
Signed-off-by: André Draszik <git@andred.net>
If we have a 'empty' macro, f.e.:
\#if <something>
\#define MY_LIBRARY_INLINE
\#endif
and using the user pattern 'MY_LIBRARY_INLINE', we would get the
following effect:
match = 'MY_LIBRARY_INLINE\n' <--- NOTE THAT THE NEWLINE IS PART OF THE MATCH
post-match = '#endif\n' <--- NO BEGINNING NEWLINE SINCE IT IS PART OF
THE MATCH ABOVE
And lead to the new header:
\#if <something>
Which gives a compilation error since the preprocessor-if is not
terminated properly.
The root cause is that we add a any-whitespace-character regex to the
user regex.
This any-whitespace-character regex was added only to cleanup the
whitespaces after a user regex.
So the next line will be deleted if we check for any whitespace
character (THIS INCLUDES A NEWLINE!) after the user regex.
But this had the side effect that when matching a user regex, the newline was
also seen as part of the match. Which in the case of an empty macro
would mean that in the cleanup of the post-match, we would delete the
line immediately after the empty macro (\#endif in the example above).
So instead of matching with every whitespace character (which includes
newlines!), we explicitly only check for whitespaces.
Taking the example above, this has the desired effect:
match = 'MY_LIBRARY_INLINE' <--- NOTE THAT THE NEWLINE IS NO LONGER PART OF THE MATCH
post-match = '\n#endif\n' <--- BEGINNING NEWLINE NOW
Now the cleanup after a define will see the beginning newline in the
post-match and only remove that newline and now the preprocessor-if is
terminated properly
First squash all multiline macro's, it makes parsing easier. Otherwise
the regex to remove the macro would become more comples if we have to
deal with newlines etc.
When we have a match, we check if the last line in the pre_match is
the beginning of a macro declaration.
If it is, we remove the beginning of this macro
declaration (#define<space>) and remove the body of the macro from the
post_match, which is basically everything until the next newline.
There is a possible edge case (pretty unlikely but still):
if there is no newline in the post_match, meaning it is a macro at the
end of the line, we should delete it as well, hence the '[\n]?' in the
post match regex.
Add a random struct in between to make sure we are not touching it
+
multiple newlines are allowed in the function declaration before the
semicolon, add a test to make sure we handle this.
When a inline function was declared in a file, we would find the
declaration and remove the function body. However, since it is a
declaration, there is NO function body, so we were deleting a random
piece of code that was between square brackets in the file.
To properly handle this, we have to detect if we are dealing with a
function declaration or a function definition.
If we are dealing with a function declaration, a semicolon
will come BEFORE the first square bracket.
If we are dealing with a function definition, a square bracket will
come BEFORE the first semicolon (the first semicolon will be in the
inline function body, so between the square brackets).
So we determine the location of the first semicolon and the first
square bracket after the function name and apply the logic described
above to handle function declarations.
If we are dealing with a function declaration, we don't do anything,
we just move to the next match.
This will result in redeclarations of the inline function, but this is
allowed in C and I'd rather not touch the file anymore than necessary.
Mark VanderVoord