ceedling 1.1.8 → 1.1.10

data/site-local/plugins/gcov/gcovr.html

@@ -2999,6 +2999,34 @@
       </ul>
     </nav>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#results-filtering" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Results filtering
+      
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Results filtering">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#overriding-the-defaults" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Overriding the defaults
+      
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
       
         <li class="md-nav__item">
@@ -4641,6 +4669,34 @@
       </ul>
     </nav>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#results-filtering" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Results filtering
+      
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Results filtering">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#overriding-the-defaults" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Overriding the defaults
+      
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
       
         <li class="md-nav__item">
@@ -5297,9 +5353,14 @@ plugin configuration. This prevents overriding config file settings with
 CLI arguments. You must provide any settings that would have been provided 
 by the Gcov plugin.</p>
 </div>
-<p>To preserve filtering of test and build files from coverage results when
-using a Gcovr config file, you must provide explicit exclusion patterns matching 
-your project layout (example below).</p>
+<p>A Gcovr config file replaces Ceedling's own automatically generated exclusion
+patterns (see <a href="#results-filtering">Results filtering</a> below) entirely — it is
+the only way to override or remove one of those defaults, since the
+project-configuration <code>:report_exclude</code> option can only add further
+exclusions on top of them, never take one away. To preserve the same
+filtering of test and build files when switching to a Gcovr config file, you
+must provide equivalent explicit exclusion patterns matching your project
+layout yourself (example below).</p>
 <div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a><span class="c1">; You will need to revise these example exclude patterns to match your</span>
 <a id="__codelineno-0-2" name="__codelineno-0-2" href="#__codelineno-0-2"></a><span class="c1">; project directories and file naming as they cannot be automatically </span>
 <a id="__codelineno-0-3" name="__codelineno-0-3" href="#__codelineno-0-3"></a><span class="c1">; provided to Gcovr when a Gcovr configuration file is in use.</span>
@@ -5312,6 +5373,84 @@ your project layout (example below).</p>
 <a id="__codelineno-0-10" name="__codelineno-0-10" href="#__codelineno-0-10"></a><span class="c1">; Build path exlcude for all generated C files (runners, mocks, partials).</span>
 <a id="__codelineno-0-11" name="__codelineno-0-11" href="#__codelineno-0-11"></a><span class="na">exclude</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">.*build/.+\.c$</span>
 </code></pre></div>
+<h2 id="results-filtering">Results filtering</h2>
+<p>By default, this plugin configures <code>gcovr</code> to excludes three categories of 
+<code>.c</code> files from coverage results. These defaults exist because a
+coverage percentage is typically only meaningful over the production code 
+you're actually trying to exercise with test coverage. Test code, test 
+support code, and every file Ceedling itself generates as part of a build 
+will skew that number if left in coverage reporting.</p>
+<p>The list that follows details the filtering this plugin injects into 
+Gcovr coverage report generation. The examples are usable regular 
+expressions that mirror the defaults in use. The plugin dynamically 
+generates these regular expressions from your project configuration.
+When creating them youself, you will need to match your project 
+configuration settings with static strings.</p>
+<ol>
+<li>
+<p><strong>Test files</strong> — matched by <code>:test_file_prefix</code> within your configured
+    <code>:paths</code> ↳ <code>:test</code> directories.</p>
+<p>Given <code>:test_file_prefix</code> ⇒ <code>test_</code> and a <code>:paths</code> ↳ <code>:test</code> entry of
+<code>test/</code>:</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a>.*test/.*/test_.+\.c$
+</code></pre></div>
+</li>
+<li>
+<p><strong>Test support files</strong> — any <code>.c</code> file within your configured <code>:paths</code> ↳
+    <code>:support</code> directories, regardless of name. Helpers, stubs, and fixtures
+    living there are no more production code than the test files themselves.</p>
+<p>Given a <code>:paths</code> ↳ <code>:support</code> entry of <code>test/support/</code>:</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-2-1" name="__codelineno-2-1" href="#__codelineno-2-1"></a>.*test/support/.+\.c$
+</code></pre></div>
+</li>
+<li>
+<p><strong>Generated and vendored files</strong> — any <code>.c</code> file anywhere below your
+    <code>:build_root</code>: generated mocks, test runners, Partials output, and the
+    vendored Unity/CMock/CException framework sources Ceedling copies in to
+    build against. This pattern always matches a literal <code>.c</code> extension
+    regardless of your project's own <code>:extension</code> ↳ <code>:source</code> setting, since
+    every file it catches is one Ceedling itself writes in plain C.</p>
+<p>Given <code>:build_root</code> ⇒ <code>build/</code>:</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-3-1" name="__codelineno-3-1" href="#__codelineno-3-1"></a>.*build/.+\.c$
+</code></pre></div>
+</li>
+</ol>
+<p>These patterns are generated automatically and combined with whatever you
+provide via <a href="#report_exclude"><code>:report_exclude</code></a> below.</p>
+<div class="admonition warning">
+<p class="admonition-title">Not applied when using a Gcovr configuration file</p>
+<p>These defaults are only generated when Ceedling builds <code>gcovr</code>'s command
+line directly. As covered in
+<a href="#gcovr-configuration-file">Gcovr configuration file</a> above, setting
+<code>:config_file</code> bypasses this entirely — none of the three patterns above
+are applied, and you must supply equivalent exclusions in the config file
+yourself.</p>
+</div>
+<h3 id="overriding-the-defaults">Overriding the defaults</h3>
+<p><a href="#report_exclude"><code>:report_exclude</code></a> can only add exclusions on top of the
+three defaults above — <code>gcovr --exclude</code> is a deny-list with no way to
+"un-exclude" a pattern already passed to it, and this plugin always passes its
+own three patterns ahead of anything you configure there. Setting
+<a href="#report_include"><code>:report_include</code></a> doesn't help either; it narrows which
+files are considered at all, but an exclude pattern still wins over it for
+any file matching both.</p>
+<p>The only way to actually remove or replace one of these defaults — for
+example, to include test files in coverage results so you can confirm a
+conditional test build compiled the branches you expect — is a
+<a href="#gcovr-configuration-file">Gcovr configuration file</a>. Setting <code>:config_file</code>
+stops Ceedling from generating any of the three patterns at all, handing you
+full control:</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-4-1" name="__codelineno-4-1" href="#__codelineno-4-1"></a><span class="c1">; gcovr.cfg — omits the test-file exclude pattern so test files remain in</span>
+<a id="__codelineno-4-2" name="__codelineno-4-2" href="#__codelineno-4-2"></a><span class="c1">; coverage results, while still keeping generated/vendored build output out.</span>
+<a id="__codelineno-4-3" name="__codelineno-4-3" href="#__codelineno-4-3"></a><span class="na">exclude</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">.*build/.+\.c$</span>
+</code></pre></div>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-5-1" name="__codelineno-5-1" href="#__codelineno-5-1"></a><span class="nt">:gcov</span><span class="p">:</span>
+<a id="__codelineno-5-2" name="__codelineno-5-2" href="#__codelineno-5-2"></a><span class="w">  </span><span class="nt">:gcovr</span><span class="p">:</span>
+<a id="__codelineno-5-3" name="__codelineno-5-3" href="#__codelineno-5-3"></a><span class="w">    </span><span class="nt">:config_file</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">gcovr.cfg</span>
+</code></pre></div>
+<p>Note that this isn't scoped per category. Once a default is dropped, any
+file it would have excluded is folded into the same combined report as your
+production code, not broken out separately.</p>
 <h2 id="plugin-configuration">Plugin configuration</h2>
 <p>The following options are exposed through your project configuration file, all
 beneath <code>:gcov</code> ↳ <code>:gcovr</code>. Only specify those you need or those whose defaults
@@ -5409,11 +5548,25 @@ is in addition to any other configured reports. (<code>gcovr --print-summary</co
 <h3 id="report_include"><code>:report_include</code></h3>
 <p>Keep only source files that match this filter. Filters are regular
 expressions. (<code>gcovr --filter</code>)</p>
+<p>This narrows which files are considered at all, but does not override
+<a href="#results-filtering">Results filtering</a>'s automatic exclusion defaults — a
+file excluded by one of those three default patterns stays excluded even if
+it also matches <code>:report_include</code>. See
+<a href="#overriding-the-defaults">Overriding the defaults</a> if you need to remove one
+of them.</p>
 <p><strong>Example:</strong> <code>"^src"</code></p>
 <hr />
 <h3 id="report_exclude"><code>:report_exclude</code></h3>
 <p>Exclude source files that match this filter. Filters are regular expressions.
 (<code>gcovr --exclude</code>)</p>
+<p>Ceedling automatically generates and prepends its own exclusion patterns for
+test files, test support files, and generated/vendored build files — see
+<a href="#results-filtering">Results filtering</a> above for exactly what these cover
+and why. Anything you provide here is combined with those defaults, not a
+replacement for them. This option can only add further exclusions, never
+remove or override one of the three defaults.
+See <a href="#overriding-the-defaults">Overriding the defaults</a> for how to do 
+that instead.</p>
 <p><strong>Example:</strong> <code>"^vendor.*|^build.*|^test.*|^lib.*"</code></p>
 <hr />
 <h3 id="gcov_filter"><code>:gcov_filter</code></h3>

data/site-local/plugins/gcov/reportgenerator.html

@@ -2999,6 +2999,56 @@
     </span>
   </a>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#results-filtering" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Results filtering
+      
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Results filtering">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#coverage-generation-filtering" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Coverage generation filtering
+      
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#report-filtering" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Report filtering
+      
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#overriding-the-defaults" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Overriding the defaults
+      
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
       
         <li class="md-nav__item">
@@ -4170,6 +4220,56 @@
     </span>
   </a>
   
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#results-filtering" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Results filtering
+      
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Results filtering">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#coverage-generation-filtering" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Coverage generation filtering
+      
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#report-filtering" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Report filtering
+      
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#overriding-the-defaults" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Overriding the defaults
+      
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
       
         <li class="md-nav__item">
@@ -4401,6 +4501,82 @@
 <a id="__codelineno-0-10" name="__codelineno-0-10" href="#__codelineno-0-10"></a><span class="w">    </span><span class="nt">:custom_args</span><span class="p">:</span>
 <a id="__codelineno-0-11" name="__codelineno-0-11" href="#__codelineno-0-11"></a><span class="w">      </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="s">&quot;-title:MyProject&quot;</span>
 </code></pre></div>
+<h2 id="results-filtering">Results filtering</h2>
+<p>This plugin filters coverage results for <code>reportgenerator</code> coverage reporting
+in two separate stages, each with its own defaults.</p>
+<h3 id="coverage-generation-filtering">Coverage generation filtering</h3>
+<p>Before <code>reportgenerator</code> ever runs, this plugin runs <code>gcov</code> itself against each
+<code>.gcno</code> file produced by the coverage test build, skipping any that match an 
+exclusion pattern — no <code>.gcov</code> data is ever produced for a skipped file, so 
+nothing downstream can put it back into a report.</p>
+<p>By default this skips:</p>
+<ul>
+<li><strong>Test files</strong> — matched by <code>:test_file_prefix</code>.</li>
+<li><strong>Mocks</strong> — matched by <code>:mock_prefix</code>.</li>
+<li><strong>Test runners</strong> — any filename containing <code>_runner</code>.</li>
+<li><strong>Vendored Unity and CMock sources</strong> — <code>unity.gcno</code> and <code>cmock.gcno</code> by
+  name.</li>
+</ul>
+<p>Given <code>:test_file_prefix</code> ⇒ <code>test_</code> and CMock's default <code>:mock_prefix</code> ⇒
+<code>Mock</code>, the equivalent filename-fragment patterns are:</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a>test_[^\/\\]*
+<a id="__codelineno-1-2" name="__codelineno-1-2" href="#__codelineno-1-2"></a>Mock[^\/\\]*
+<a id="__codelineno-1-3" name="__codelineno-1-3" href="#__codelineno-1-3"></a>[^\/\\]*_runner[^\/\\]*
+<a id="__codelineno-1-4" name="__codelineno-1-4" href="#__codelineno-1-4"></a>unity
+<a id="__codelineno-1-5" name="__codelineno-1-5" href="#__codelineno-1-5"></a>cmock
+</code></pre></div>
+<p>These combine with whatever you add via <a href="#gcov_exclude"><code>:gcov_exclude</code></a>
+below. Your patterns extend this list, they don't replace it.</p>
+<h3 id="report-filtering">Report filtering</h3>
+<p>Separately, once <code>.gcov</code> files exist, ReportGenerator's own <code>-filefilters:</code>
+argument controls which of them actually appear in the generated report(s).
+By default this excludes:</p>
+<ol>
+<li>
+<p><strong>Test paths</strong> — every file anywhere under each of your configured
+    <code>:paths</code> ↳ <code>:test</code> directories, not only files matching
+    <code>:test_file_prefix</code>. A support subdirectory nested under a test path
+    (e.g. <code>test/support/</code>) is excluded as a side effect of this — the whole
+    tree goes, not just prefixed test files.</p>
+<p>Given a <code>:paths</code> ↳ <code>:test</code> entry of <code>test/</code>:
+<div class="highlight"><pre><span></span><code><a id="__codelineno-2-1" name="__codelineno-2-1" href="#__codelineno-2-1"></a>-./test/**/*
+</code></pre></div></p>
+</li>
+<li>
+<p><strong>The build root</strong> — every generated and vendored file: mocks, test
+    runners, Partials output, Unity, CMock, CException.</p>
+<p>Given <code>:build_root</code> ⇒ <code>build/</code>:
+<div class="highlight"><pre><span></span><code><a id="__codelineno-3-1" name="__codelineno-3-1" href="#__codelineno-3-1"></a>-./build/**/*
+</code></pre></div></p>
+</li>
+<li>
+<p><strong>Partial-generated files</strong> — only when <code>:use_partials</code> is enabled, any
+    file whose name starts with Ceedling's Partial filename prefix, wherever
+    it's found (not only under the build root).</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-4-1" name="__codelineno-4-1" href="#__codelineno-4-1"></a>-ceedling_partial_*
+</code></pre></div>
+</li>
+</ol>
+<p>These patterns are generated automatically and placed ahead of whatever you
+provide via <a href="#file_filters"><code>:file_filters</code></a> below.</p>
+<h3 id="overriding-the-defaults">Overriding the defaults</h3>
+<p>Neither filtering stage above can be overridden or narrowed by plugin
+configuration — only added to.</p>
+<p>For <a href="#coverage-generation-filtering">coverage generation filtering</a>,
+<a href="#gcov_exclude"><code>:gcov_exclude</code></a> only ever adds more exclusion patterns; there
+is no plugin option to disable one of the built-in exclusions, and no way to
+resurrect <code>.gcov</code> data for a file <code>gcov</code> was never run against in the first
+place.</p>
+<p>For <a href="#report-filtering">report filtering</a>, the natural instinct is to reach
+for <a href="#custom_args"><code>:custom_args</code></a> to pass a second, conflicting
+<code>-filefilters:</code> argument, but this is not an option because of ReportGenerator's
+rules and the order in which the filters are provided by the plugin.</p>
+<p>In short, there's no supported way to broaden what this plugin reports
+beyond its defaults. If you need to override coverage reporting filtering, 
+use the <a href="gcovr.html">Gcovr option for this pluing</a> instead. Its
+<code>:config_file</code> option hands full control to a <code>gcovr</code> configuration file,
+bypassing Ceedling's generated exclusions entirely (see
+<a href="gcovr.html#results-filtering">Gcovr's Results filtering</a>).</p>
 <h2 id="plugin-configuration">Plugin configuration</h2>
 <h3 id="history_directory"><code>:history_directory</code></h3>
 <p>Optional directory for storing persistent coverage information. Can be used
@@ -4426,10 +4602,15 @@ filters. Wildcards are allowed, but not regular expressions.</p>
 <h3 id="file_filters"><code>:file_filters</code></h3>
 <p>Optional list of files that should be included or excluded in the report
 (separated by semicolon). Exclusion filters take precedence over inclusion
-filters. Wildcards are allowed, but not regular expressions. Ceedling places
-your own patterns first, ahead of the exclusions it generates automatically
-for test paths, the build root, and (when Partials are in use) Partial
-source files, so your patterns take precedence.</p>
+filters regardless of order. Wildcards are allowed, but not regular
+expressions.</p>
+<p>This plugin places your own patterns first, ahead of the exclusions it
+generates automatically for test paths, the build root, and (when Partials
+are in use) Partial-generated files (see
+<a href="#report-filtering">Report filtering</a> above for exactly what those defaults
+cover). Because exclusions always win, your patterns can add further
+exclusions or includes but cannot override or remove one of those defaults;
+see <a href="#overriding-the-defaults">Overriding the defaults</a> above.</p>
 <p><strong>Example:</strong> <code>"-./vendor/*;-./build/*;-./test/*;-./lib/*;+./src/*"</code></p>
 <hr />
 <h3 id="verbosity"><code>:verbosity</code></h3>
@@ -4445,11 +4626,17 @@ source files, so your patterns take precedence.</p>
 (<code>.gcno</code>) files that match these filters from coverage processing — these
 files are never run through <code>gcov</code> at all. A trailing <code>.gcov</code> or <code>.gcno</code>
 suffix on a pattern is stripped automatically, so either form works.</p>
-<div class="highlight"><pre><span></span><code><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a><span class="nt">:gcov</span><span class="p">:</span>
-<a id="__codelineno-1-2" name="__codelineno-1-2" href="#__codelineno-1-2"></a><span class="w">  </span><span class="nt">:report_generator</span><span class="p">:</span>
-<a id="__codelineno-1-3" name="__codelineno-1-3" href="#__codelineno-1-3"></a><span class="w">    </span><span class="nt">:gcov_exclude</span><span class="p">:</span>
-<a id="__codelineno-1-4" name="__codelineno-1-4" href="#__codelineno-1-4"></a><span class="w">      </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">&lt;regex&gt;</span>
-<a id="__codelineno-1-5" name="__codelineno-1-5" href="#__codelineno-1-5"></a><span class="w">      </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">...</span>
+<p>Ceedling combines your patterns with exclusions it generates automatically
+for test files, mocks, test runners, and vendored Unity/CMock sources (see
+<a href="#coverage-generation-filtering">Coverage generation filtering</a> above for
+exactly what these cover). Your patterns can only add further exclusions;
+there's no way to override or remove one of the defaults — see
+<a href="#overriding-the-defaults">Overriding the defaults</a> above.</p>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-5-1" name="__codelineno-5-1" href="#__codelineno-5-1"></a><span class="nt">:gcov</span><span class="p">:</span>
+<a id="__codelineno-5-2" name="__codelineno-5-2" href="#__codelineno-5-2"></a><span class="w">  </span><span class="nt">:report_generator</span><span class="p">:</span>
+<a id="__codelineno-5-3" name="__codelineno-5-3" href="#__codelineno-5-3"></a><span class="w">    </span><span class="nt">:gcov_exclude</span><span class="p">:</span>
+<a id="__codelineno-5-4" name="__codelineno-5-4" href="#__codelineno-5-4"></a><span class="w">      </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">&lt;regex&gt;</span>
+<a id="__codelineno-5-5" name="__codelineno-5-5" href="#__codelineno-5-5"></a><span class="w">      </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">...</span>
 </code></pre></div>
 <p><strong>Default:</strong> <code>[]</code></p>
 <hr />
@@ -4467,11 +4654,11 @@ covered by the options above. See the
 <p>Note: This can be accomplished with Ceedling's tool configuration options
 outside of plugin configuration but is supported here to collect
 configuration options in one place.</p>
-<div class="highlight"><pre><span></span><code><a id="__codelineno-2-1" name="__codelineno-2-1" href="#__codelineno-2-1"></a><span class="nt">:gcov</span><span class="p">:</span>
-<a id="__codelineno-2-2" name="__codelineno-2-2" href="#__codelineno-2-2"></a><span class="w">  </span><span class="nt">:report_generator</span><span class="p">:</span>
-<a id="__codelineno-2-3" name="__codelineno-2-3" href="#__codelineno-2-3"></a><span class="w">    </span><span class="nt">:custom_args</span><span class="p">:</span>
-<a id="__codelineno-2-4" name="__codelineno-2-4" href="#__codelineno-2-4"></a><span class="w">      </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">&lt;argument&gt;</span>
-<a id="__codelineno-2-5" name="__codelineno-2-5" href="#__codelineno-2-5"></a><span class="w">      </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">...</span>
+<div class="highlight"><pre><span></span><code><a id="__codelineno-6-1" name="__codelineno-6-1" href="#__codelineno-6-1"></a><span class="nt">:gcov</span><span class="p">:</span>
+<a id="__codelineno-6-2" name="__codelineno-6-2" href="#__codelineno-6-2"></a><span class="w">  </span><span class="nt">:report_generator</span><span class="p">:</span>
+<a id="__codelineno-6-3" name="__codelineno-6-3" href="#__codelineno-6-3"></a><span class="w">    </span><span class="nt">:custom_args</span><span class="p">:</span>
+<a id="__codelineno-6-4" name="__codelineno-6-4" href="#__codelineno-6-4"></a><span class="w">      </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">&lt;argument&gt;</span>
+<a id="__codelineno-6-5" name="__codelineno-6-5" href="#__codelineno-6-5"></a><span class="w">      </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">...</span>
 </code></pre></div>
 <p><strong>Default:</strong> <code>[]</code></p>
 <p><br/><br/></p>

data/spec/system/partials_types_header_spec.rb

@@ -0,0 +1,166 @@
+# =========================================================================
+#   Ceedling - Test-Centered Build System for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2010-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
+require 'spec_system_helper'
+
+##
+## Shared Partials Types Header (issue #1319)
+## ==========================================
+##
+## Partials lifts a module's type definitions into one shared header so a module tested and
+## mocked in the same test file still gets exactly one C definition of each type. That header
+## lands in the generated include lists at the position the module's own header occupied, which
+## is earlier than the module's own source placed its dependencies.
+##
+## Until this fix the shared header emitted no #include directives at all, so it compiled only
+## where something earlier in the translation unit happened to have declared the names its
+## extracted types reference. A module whose header declares a type in terms of one another
+## header supplies failed with `unknown type name`, and the same gap applied to a macro an
+## extracted type names.
+##
+## The header now carries those dependencies itself, and states the real module header's include
+## guard deliberately so a transitive reach at that header finds it already satisfied.
+##
+
+ceedling_system_tests do
+
+  before :all do
+    @c = SystemContext.new
+    @c.deploy_gem
+  end
+
+  after :all do
+    @c.done!
+  end
+
+  before { @proj_name = unique_proj_name("partials_types") }
+
+  describe "Deployed as a gem" do
+    before do
+      @c.with_context do
+        @c.ceedling_appcmd_exec("new #{@proj_name}")
+      end
+    end
+
+    # =========================================================================
+    describe "a Partial's extracted types depending on another header" do
+    # =========================================================================
+
+      before do
+        @c.with_context do
+          Dir.chdir @proj_name do
+            File.write('src/units.h', <<~C)
+              #ifndef UNITS_H
+              #define UNITS_H
+
+              typedef signed short Celsius;
+
+              #endif // UNITS_H
+            C
+            File.write('src/sensor.h', <<~C)
+              #ifndef SENSOR_H
+              #define SENSOR_H
+
+              #include "units.h"
+
+              typedef struct
+              {
+                  Celsius limit;
+              } SensorConfig;
+
+              int sensor_over_limit(Celsius reading);
+
+              #endif // SENSOR_H
+            C
+            File.write('src/sensor.c', <<~C)
+              #include "sensor.h"
+
+              static SensorConfig config = { .limit = 30 };
+
+              static Celsius sensor_limit(void)
+              {
+                  return config.limit;
+              }
+
+              int sensor_over_limit(Celsius reading)
+              {
+                  return reading > sensor_limit();
+              }
+            C
+            File.write('test/test_sensor.c', <<~C)
+              #ifdef TEST
+
+              #include "unity.h"
+              #include "ceedling.h"
+
+              #include TEST_PARTIAL_ALL_MODULE(sensor)
+
+              void setUp(void) {}
+              void tearDown(void) {}
+
+              void test_sensor_reads_its_own_file_scope_config(void)
+              {
+                  TEST_ASSERT_EQUAL_INT(30, sensor_limit());
+              }
+
+              void test_sensor_over_limit_uses_the_exposed_limit(void)
+              {
+                  config.limit = 10;
+                  TEST_ASSERT_TRUE(sensor_over_limit(11));
+                  TEST_ASSERT_FALSE(sensor_over_limit(9));
+              }
+
+              #endif // TEST
+            C
+
+            @c.merge_project_yml_for_test( :project => { :use_partials => true } )
+          end
+        end
+      end
+
+      # Exercises the whole chain at once: the carried dependency makes the shared types header
+      # compile, the stripped `static` on a file-scope variable makes it reachable from the test,
+      # and the stripped `static` on a function makes it callable.
+      it "builds and passes, reaching the module's exposed statics" do
+        @c.with_context do
+          Dir.chdir @proj_name do
+            output = @c.ceedling_build_exec("test:all")
+
+            expect(@c.last_exit_status).to eq(0), "build failed:\n#{output}"
+            expect(output).to match(/TESTED:\s+2/)
+            expect(output).to match(/PASSED:\s+2/)
+            expect(output).to match(/FAILED:\s+0/)
+          end
+        end
+      end
+
+      # The dependency the shared header carries, and the guard it spoofs, are both emitted into
+      # the generated file. Reading it directly states what the build result alone cannot show.
+      it "carries the dependency and spoofs the real header's guard" do
+        @c.with_context do
+          Dir.chdir @proj_name do
+            @c.ceedling_build_exec("test:all")
+
+            generated = Dir.glob('build/test/partials/**/*sensor_types.h').first
+            expect(generated).not_to be_nil, 'no shared types header was generated'
+
+            contents = File.read(generated)
+            expect(contents).to match(/#include\s+"units\.h"/)
+            expect(contents).to match(/^#define SENSOR_H$/)
+
+            # The spoof has to precede the carried include: that include can reach the real
+            # module header in turn, and the guard must already be satisfied when it does.
+            expect(contents.index('#define SENSOR_H')).to be < contents.index('#include "units.h"')
+          end
+        end
+      end
+
+    end
+
+  end
+
+end