coverage: keep same-named functions from different builds apart - #7141
Conversation
`ci/gcc-clang` now has a build on the default gembox, which compiles
without `MRB_UTF8_STRING`, alongside the three that take `full-core`. A
source file that defines a function twice under `#ifdef MRB_UTF8_STRING`
and `#else` therefore reaches gcovr as two functions of the same name on
different lines of the same file, and its default `strict` function
merge mode rejects that:
mrbgems/mruby-string-ext/src/string.c:1026 Got function str_ord on
multiple lines: 1026, 1222.
The report step then exits 64 and the job fails, though every test in it
passed. `str_ord` is only where gcovr stops first; `str_codepoints`,
`str_scrub_core` and `mrb_str_char_len` collide the same way.
Pass --merge-mode-functions=separate. The two definitions are distinct
function bodies that no single build ever holds at once, so counting
them as separate functions is what the source says; merging them into
one line number would not be.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe coverage workflow now passes ChangesCoverage Configuration
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This is a localized CI configuration change that separates same-named coverage functions across builds and restores report generation; no actionable merge-blocking risk remains after normal checks and review. Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
2 participants
The Coverage job on
masterhas been failing since #7138 was merged. Every test in it passes; the job dies in the report step.#7138 added a build on the default gembox to
ci/gcc-clang, so for the first time the coverage run holds gcov data from a build withoutMRB_UTF8_STRINGnext to data from three that takefull-core. A source file that defines a function twice, once under#ifdef MRB_UTF8_STRINGand once under#else, then reaches gcovr as two functions of the same name on different lines of one file, and gcovr's defaultstrictfunction merge mode treats that as an error:gcovr exits 64 and the job fails.
str_ordis just where it stops first:str_codepoints,str_scrub_coreandmrb_str_char_lenare the same shape, so fixing one name at a time would not get the job green.This passes
--merge-mode-functions=separate. The two definitions are distinct function bodies and no single build ever holds both, so counting them as two functions is what the source says; the merging modes would instead fold them onto one line number, which describes neither build.I reproduced the failure and the fix outside mruby with gcovr 8.6, on the smallest program of this shape: one
staticfunction defined twice under#ifdefand#else, compiled--coverageinto two directories with the macro on and off. gcovr's default mode raises the sameGcovrMergeAssertionErrorand exits 64; with--merge-mode-functions=separatethe report is generated and counts both bodies.This follows 01e1e2b, which reached for a gcovr flag the same way when the Prism sources made gcov fail to resolve paths.
Summary by CodeRabbit