This reverts commit 7fbeb4096535550af8ff74308107e805088de2d5.
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.
It didn't add direct comparisons only for pointer arguments, but
also other types of arguments like structs, which can't be compared
with '==' and cause a compiler error instead.
To reproduce, just enable the :array plugin in
system/test_interactions/expect_and_return_custom_types.yml:
In function ‘foo’:
error: invalid operands to binary != (have ‘EXAMPLE_STRUCT_T’ {aka
‘struct _EXAMPLE_STRUCT_T’} and ‘EXAMPLE_STRUCT_T’ {aka ‘struct
_EXAMPLE_STRUCT_T’})
59 | if (cmock_call_instance->Expected_a != a) {
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~
This reverts commit 4df532afccb7e7d1437f79764cc3b0619302c822.
- We set the defaults but the user is free to add his own.
This will overwrite our defaults but they will be added to the
documentation as reference for the user
- Just looking for static|inline in the gsub is a bit too aggressive.
Instead, look for the "static inline" and parse it:
- Everything before the match should just be copied, we don't want
to touch anything but the inline functions.
- Remove the implementation of the inline function (this is enclosed
in square brackets) and replace it with ";" to complete the
transformation to normal/non-inline function.
- Copy everything after the inline function implementation
Repeat the above step until we can't find "static inline" anymore
- To remove the inline implementation,
we count the number of square-bracket 'levels' in the inline function
and remove every pair. This ensures that constructs like:
inline void func(void) {
if (...) {
//NOP
}
else
{
//NOP
}
}
will not end up leaving the 'else' keyword unremoved:
inline void func(void);
else
If we count the number of levels, we don't end up in this scenario
since we remove 3 'pairs', the if-one, the else-one and finally the
main body.
