CMock: static inline functions result in incorrectly generated mocks
When I try to mock driver functions from a file in the NRF5 SDK that contain static inline functions the generated mocks seem broken.
For example, lets have a module in my app called timekeeper.c that depends upon nrfx_rtc.h (which should be mocked).
The two errors I can see in the generated mocks are:
- The include path in the generated mock file is a full relative path, rather than being relative to the include directories specified in
project.yml. Therefore it results in the file not being able to be discovered?
Test 'test_timekeeper.c'
------------------------
Generating include list for nrfx_rtc.h...
Creating mock for nrfx_rtc...
In file included from build/test/mocks/mock_nrfx_rtc.h:6,
from test/test_timekeeper.c:4:
build/test/mocks/nrfx_rtc.h:1:10: fatal error: sdk/nRF5_SDK_16.0.0_98a08e2/modules/nrfx/hal/nrf_rtc.h: No such file or directory
1 | #include "sdk/nRF5_SDK_16.0.0_98a08e2/modules/nrfx/hal/nrf_rtc.h"
- When I try and mock one of the functions that happens to be
static inlineinnrfx_rtc.hby using:cmock: :treat_inlines: :includeinproject.yml, the output atbuild/test/mocks/nrf_rtc.hcontains TWO different definitions for each original instance ofstatic inlinefunctions… one that isstatic inlineand one that is not…e.g.
uint32_t nrfx_rtc_counter_get(nrfx_rtc_t const * const p_instance);
// ..... later on
static inline uint32_t nrfx_rtc_counter_get(nrfx_rtc_t const * const p_instance);
That is about as deep as I am able to trace things down. When I manually edit the generated files to have the correct include path, it chokes on the two different definitions. When I try and manually remove one of the definitions just to see what would happen, the test never executes
Test 'test_timekeeper.c'
------------------------
Compiling test_timekeeper_runner.c...
Compiling test_timekeeper.c...
Compiling mock_nrfx_rtc.c...
Compiling unity.c...
Compiling timekeeper.c...
Compiling cmock.c...
Linking test_timekeeper.out...
Running test_timekeeper.out...
ERROR: Test executable "test_timekeeper.out" failed.
> Produced no output to $stdout.
> And exited with status: [0] (count of failed tests).
> This is often a symptom of a bad memory access in source or test code.
rake aborted!
/home/brett/workspace/avatech/scope/vendor/ceedling/lib/ceedling/generator_helper.rb:36:in `test_results_error_handler'
/home/brett/workspace/avatech/scope/vendor/ceedling/lib/ceedling/generator.rb:170:in `generate_test_results'
/home/brett/workspace/avatech/scope/vendor/ceedling/lib/ceedling/rules_tests.rake:55:in `block in <top (required)>'
/home/brett/workspace/avatech/scope/vendor/ceedling/lib/ceedling/task_invoker.rb:102:in `invoke_test_results'
/home/brett/workspace/avatech/scope/vendor/ceedling/lib/ceedling/test_invoker.rb:144:in `block in setup_and_invoke'
/home/brett/workspace/avatech/scope/vendor/ceedling/lib/ceedling/test_invoker.rb:76:in `each'
/home/brett/workspace/avatech/scope/vendor/ceedling/lib/ceedling/test_invoker.rb:76:in `setup_and_invoke'
/home/brett/workspace/avatech/scope/vendor/ceedling/lib/ceedling/rules_tests.rake:71:in `block (2 levels) in <top (required)>'
/home/brett/.gem/ruby/2.7.0/gems/ceedling-0.29.1/bin/ceedling:334:in `block in <top (required)>'
/home/brett/.gem/ruby/2.7.0/gems/ceedling-0.29.1/bin/ceedling:321:in `<top (required)>'
/home/brett/.gem/ruby/2.6.0/bin/ceedling:23:in `load'
/home/brett/.gem/ruby/2.6.0/bin/ceedling:23:in `<main>'
Tasks: TOP => build/test/results/test_timekeeper.pass
(See full trace by running task with --trace)
--------------------
OVERALL TEST SUMMARY
--------------------
No tests executed
About this issue
- Original URL
- State: open
- Created 3 years ago
- Comments: 29 (8 by maintainers)
@bigbrett Please go to vendor folder in your project and remove ceedling folder. Next clone my branch in this folder:
Next try to run
ceedling clobber test:allYou should have this output:Of course there is a warning but I think you should change
#define FLASH_ADDR (0xFEEDBEEF)to#define FLASH_ADDR (void *)(0xFEEDBEEF)If anybody interested I updated my branch. Now I’m trying to cheat compiler to use generated header with the highest priority by the
-include fileoption from gcc which can help to “Process file as if #include “file” appeared as the first line of the primary source file.”.Hi! I’m trying to fix it in ceedling when preprocessor is enabled. If anybody interested here is my branch for tests. I think ceedling shouldn’t take preprocessed header with expanded include paths to generate parsed header with non-inline functions. When
:treat_inlinesoption is disabled then generated mock points to real unpreprocessed header, so when:treat_inlinesis set to:includemock also should points to generated header which is not preprocessed and let compiler to preprocess and compile everything in the next steps. At this moment I have to generate mock twice, once for unpreprocessed header to generate header without inlines, and next again to generate mock based on preprocessed header.Oh damn, sorry completely missed that part… Will read @Letme 's comment a bit more in detail cause the rabbit hole seems to be deeper than I thought.
Some quick observations: cmock seems to receive the header with already a full relative path iso
#include "fsl_common.h"as source-to-be-parsed when it gets to mocking it (+transforming the inline functions), so it’s happening before cmock gets to touch the file. If I disable the test preprocessor (inproject.yml::use_test_preprocessor: FALSEisoTRUE) in your example code, I don’t see the issue.I know the testprocessor setting runs the test files and headers through the gcc preprocessor and hands these outputs to ceedling/cmock to be parsed (so cmock doesn’t know about the original include here actually…), but I wouldn’t expect him to change paths like this (but again, this may be due to my lack of knowledge) Will try to understand this better but can’t promise a solution. To fix this (very crude solution), cmock would need to know the original file (or have access to its original non-preprocessed sources) and use that to generate the non-inline header. However, I guess some users want this behaviour, so you would need a way to flag a header as use_test_preprocessor or not, which quickly becomes a mess I fear.
EDIT: Using the test preprocessor together with the static-inline mocking is giving several issues ( I think #328 is also related to this). To be honest, I don’t know what the best solution is to be able to use these together. I’d have to look more into what ceedling does with the headers and how it calls cmock for generating the mocks.
As an easy answer: The core of unit testing is to swap paths, so if you have
/bla/sub/folder/unit.hyou want to have it inbuild/bla/sub/folder/unit.h. Now, this can become a problem with relative paths and hence we should only#include "unit.h"and let the linker do the path swapping.I went a bit through your example and I see the issue where gcc
includes_preprocessor_toolreturnscommon/hal/fsl_common.has include path. Not sure if this is new or something, but it seems wrong:I also moved the test file around different subfolders and that makes no effect, so its purely something to do with preprocessor and adding includes. I think somehow that relative path is added to the file, while it is skipped for non-inline parser. Same as you, my Ruby knowledge is basically non-existent, so all you can do is wait…