ceedling 1.1.8 → 1.1.10

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 3c1edc565bc9fcb24accc9fd0d5001076fe86564cb0acd02c7d1fc092476c2c1
-  data.tar.gz: 0c5ec0119bc3249824177c6094afd3e3ef9ee7da698b92fed894924d45d83625
+  metadata.gz: 828ad43a2f6d106ff54bb18fcb6bab61f3c9164f1ae7f2c2923d8739f0351696
+  data.tar.gz: d0f1bd257e32aa6c45cb1166904a124ea4f2f5bb17c6e3504a5c8b3e7b7bce28
 SHA512:
-  metadata.gz: 6efc0307567637d4019978131f45758d694b97ea93a4a7ada5ff6be8c682d70eff9d8d453de4882cc46344bb1b0aa098dbf7982582a7d7a168818caba2bd7e51
-  data.tar.gz: 6366fddeaff5572f317efffb161ff64378cae4e6b2dea30aa11f3baf4aac1777611331483d071a080cb9a01aa1e4087409d5314559881ae0a12ce753a1f86311
+  metadata.gz: 40b9742b2c4bc7deb08a52e2281cf81b4684bbcdb08ac5b3dcffd6d0ee2af087c7cda184764938bb54bbb5b1c5e9d6fd17d822468cbc8b579667a21228917ca7
+  data.tar.gz: 67be8904bf70f79f954b13a4fcfd8b47805fc82e5a2ea3e1af7b82463759dcf08846c75638b280f19f38538a212cc91d958dcde785729377f654411c3de69ef3

data/GIT_COMMIT_SHA

@@ -1 +1 @@
-885dc91
+85ec551

data/README.md

@@ -1,7 +1,7 @@
 Ceedling ![CI](https://github.com/ThrowTheSwitch/Ceedling/workflows/CI/badge.svg)
 ========
 
-**Ceedling 1.1.8** is the latest and greatest.
+**Ceedling 1.1.10** is the latest and greatest.
 
 See [_Release Notes_][release-notes], [_Changelog_](docs/Changelog.md), 
 [_Breaking Changes_][breaking-changes], and [_Known Issues_][known-issues].
@@ -472,10 +472,10 @@ Matt Chernosky’s **[detailed tutorial][tutorial]** demonstrates using Ceedling
 
 ### Local installation from the RubyGems repository
 
-1. Install [Ruby]. (Only Ruby 3+ supported.)
+1. Install [Ruby]. (Ceedling requires Ruby 3+ but only unoficially supports Ruby 4.)
 1. Install the Ceedling gem from the RubyGems repository. All supporting frameworks are included and this style of installation installs dependencies as well.
    ```shell
-   > gem install ceedling
+   > gem install ceedling --no-document
    ```
 1. Begin crafting your project:
    1. Create an empty Ceedling project.
@@ -487,6 +487,7 @@ Matt Chernosky’s **[detailed tutorial][tutorial]** demonstrates using Ceedling
    ```shell
    > ceedling test:all release
    ```
+
 ### Local installation of the .gem file downloaded from this repo
 
 If you are working with prerelease versions of Ceedling or some other off-the-beaten-path installation scenario, you may want to directly install the Ceedling .gem file attached to any of the Github releases. No problem.

data/docs/Changelog.md

@@ -10,6 +10,34 @@ This changelog is complemented by three other documents:
 
 ---
 
+# [1.1.10] — 2026-10-07
+
+## 💪 Fixed
+
+### Partials
+
+- [#1319](https://github.com/ThrowTheSwitch/Ceedling/issues/1319) Fixed a Partials-generated types header leaving out the `#include` directives its extracted types need, causing an `unknown type name` or `undeclared here` compilation error. The generated header now carries its needed headers itself and no longer depends on the incidental order of includes before it.
+
+---
+
+# [1.1.9] — 2026-09-20
+
+## 💪 Fixed
+
+### Partials
+
+- [#1293](https://github.com/ThrowTheSwitch/Ceedling/issues/1293) Fixed a Partials-generated header occasionally redefining a type already declared by the real header it replaces, causing a `typedef redefinition with different types` compilation error. The triggering condition involved a source file whose real header was reachable both directly and through a macro-included intermediate file allowed by incomplete Partials include directive ordering.
+
+### Preprocessing
+
+- Fixed whitespace occasionally inserted by the underlying compiler's preprocessor around a `#` or `##` operator (e.g. `x ##y` becoming `x ## y`) being carried through verbatim into Partials-generated and reconstructed macro definitions. Extracted macro text is now normalized so preprocessing stringize and token-paste operators always sit directly against their operands, regardless of what a given toolchain's preprocessor happens to emit.
+
+## ⚠️ Changed
+
+- Updated Unity to latest version.
+
+---
+
 # [1.1.8] — 2026-09-10
 
 ## 💪 Fixed

data/docs/KnownIssues.md

@@ -17,13 +17,23 @@ Known issues are complemented by three other documents:
 ## 1.1.0 — 2026-07-16
 
 1. The new internal pipeline as of 1.0.0 that allows builds to be parallelized and configured per-test-executable can mean a fair amount of duplication of steps. A header file may be mocked identically multiple times. The same source file may be compiled identically multiple times. The speed gains due to parallelization help make up for this. Future releases will concentrate on optimizing away duplication of build steps.
-1. While header file search paths are now customizable per executable, this currently only applies to the search paths the compiler uses. Distinguishing test files or header files of the same name in different directories for test runner and mock generation respectively continues to rely on educated guesses in Ceedling code.
+1. While header file search paths are now customizable per executable, this currently only applies to the search paths the compiler uses. Distinguishing test files or header files of the same name in different directories for test runner and mock generation respectively continues to rely on educated guesses in Ceedling code. Support for full path-qualified disambiguation will arrive in 1.2.0.
 1. All header files needed for test compilation must be within the `:includes` path collection. Relative paths in include directives that extend outside the path collection will cause build problems.
 1. Any path for a C file specified with `TEST_SOURCE_FILE(...)` is in relation to **_project root_** — that is, from where you execute `ceedling` at the command line. If you move source files or change your directory structure, many of your `TEST_SOURCE_FILE(...)` calls may need to be updated. A more flexible and dynamic approach to path handling will come in a future update.
 1. In certain combinations of conditional preprocessing blocks with dependent symbols defined in another file, Ceedling can silently fail to extract computed includes (e.g. `#include SOME_MACRO()`).
-1. User includes (`#include "path/user.h"`) from source C files lose their relative path when Partial and mock header files are generated from source. Compilation failures can result from certain uncommon cases involving headers of the same names in different directories and a source file including both such headers.
+1. The automatic vendor copying of Unity, CMock, and CException into a project's build directory can intermittently fail with a file/directory type error, most often under antivirus/EDR file locking, cloud-sync filter drivers, or two concurrent Ceedling invocations racing the same destination. Deleting `build/` (or reinstalling the gem) and rebuilding works around it.
 1. The Bullseye code coverage plugin has been temporarily disabled as of 1.0.0. The makers of Bullseye have generously provided a license for development, and the plugin will be available in the next minor release.
 
+### Partials
+
+1. User includes (`#include "path/user.h"`) from source C files lose their relative path when Partial and mock header files are generated from source. Compilation failures can result from certain uncommon cases involving headers of the same names in different directories and a source file including both such headers.
+1. Partial directive macros accept only a bare module name — a filename stem with no path. A project holding two modules of the same name in different directories cannot say which of them a Partial is for, and Ceedling resolves the name the way a compiler resolves a header, selecting the first match among the ordered search paths. Path-qualified Partial macros will arrive in 1.2.0.
+1. A module whose header protects itself with `#pragma once` instead of a traditional `#ifndef` include guard can still hit a `redefinition` or `conflicting types` error, if any other header your module uses reaches that header in turn. Ceedling suppresses the real header by defining its include guard, and `#pragma once` provides no guard to define. Converting the module’s header to a traditional include guard works around it.
+1. A `struct`, `union`, or `enum` written directly on a variable, as in `static struct { int depth; } slot;`, is treated as a variable alone. The generated Partial states the type twice and fails to compile.
+1. A `struct`, `union`, or `enum` named but not defined, as in `struct node;`, is reproduced in the generated Partial as an invalid declaration. Builds treating warnings as errors fail on it.
+1. A macro the module retires with `#undef` is carried into the generated Partial anyway, so the name stays visible to your test file and can collide with another macro of the same name.
+1. Exposing a module’s file-scope variables and functions removes what kept their names private to that module. Two Partialized modules in one test file that each use the same name for a file-scope variable collide at link time.
+
 ---
 
 ## 1.0.0 — 2025-01-01

data/docs/SECURITY.md

@@ -7,6 +7,34 @@ projects, including `Unity`, `CMock`, and `Ceedling`.
   * [Disclosure Policy](#disclosure-policy)
   * [Comments on this Policy](#comments-on-this-policy)
 
+## Automated Security Scanner False Positives
+
+Ceedling is built with Ruby, and Ruby’s package manager (RubyGems/Bundler)
+caches a local index of the *entire* public RubyGems.org registry in order
+to resolve dependencies (e.g. `~/.gem/specs/rubygems.org%443/specs.4.8`).
+That cache lists every gem ever published to RubyGems.org — including many
+completely unrelated to Ceedling whose names happen to reference
+cryptocurrency, wallets, or mining. An automated scanner that searches this
+cache file for such keywords will find matches purely because of what
+RubyGems.org hosts, not because of anything in Ceedling’s own code or its
+declared dependencies.
+
+If your organization’s security tooling flags a Ceedling installation for
+cryptocurrency-related content, check first whether the flagged file
+originates from a Ruby/RubyGems package cache rather than from Ceedling’s
+own source tree. Ceedling’s actual dependencies are declared in `Gemfile`
+and `ceedling.gemspec`, neither of which includes any cryptocurrency,
+wallet, or mining related package.
+
+Separately, Ceedling’s core function is compiling and running C test
+executables. A scanner that flags a compiled test binary (e.g. a `.out` or
+`.exe` file) as a suspicious executable is correctly observing Ceedling
+doing its job, not a symptom of a security issue.
+
+See [issue #940](https://github.com/ThrowTheSwitch/Ceedling/issues/940) for
+an example of this exact false positive, including the specific package-cache 
+evidence.
+
 ## Reporting a Bug
 
 The tools from `ThrowTheSwitch.org` are made to collaborate with other tools like compilers, 
@@ -19,8 +47,18 @@ make every effort to improve our tools safe use. Thank you for improving the sec
 our tools. We appreciate your efforts and responsible disclosure and will make every effort 
 to acknowledge your contributions.
 
-Report security bugs by opening a Github Issue on the corresponding project or (when this
-itself would pose a risk) by emailing security@thingamabyte.com.
+Report security bugs using the corresponding
+[ThrowTheSwitch project’s](https://github.com/ThrowTheSwitch/) private vulnerability 
+reporting feature on GitHub 
+[[jump to Ceedling’s private vulnerability reporting](https://github.com/ThrowTheSwitch/Ceedling/security/advisories/new)]:
+
+1. From the project’s repository page, select the **_Security_** tab
+2. Then **_Report a vulnerability_**.
+
+This opens a private advisory visible only to maintainers, rather than a public GitHub Issue
+that would expose the vulnerability before a fix is available. If a ThrowTheSwitch project 
+has not yet enabled this feature, or you would rather not use GitHub, email 
+[security@thingamabyte.com](mailto:security@thingamabyte.com) instead.
 
 Report security bugs in third-party modules to the person or team maintaining
 the module.

data/docs/mkdocs/development/index.md

@@ -18,6 +18,14 @@
     Guidelines for contributing to this project — be it code, reviews,
     documentation, or issue reports.
 
+-   :material-shield-lock: **[Security][security]**
+
+    ---
+
+    See the [policy][security-policy] for disclosure details and
+    guidance on issues that vulnerability inspection tools may surface.
+    Report a vulnerability through a [private advisory][security-report].
+
 </div>
 
 ## Projects
@@ -46,5 +54,8 @@
 [code-of-conduct]:  https://github.com/ThrowTheSwitch/Ceedling/blob/master/docs/CODE_OF_CONDUCT.md
 [contributing]:     https://github.com/ThrowTheSwitch/Ceedling/blob/master/docs/CONTRIBUTING.md
 [dev-workflow]:     workflow.md
+[security]:         https://github.com/ThrowTheSwitch/Ceedling?tab=security-ov-file
+[security-policy]:  https://github.com/ThrowTheSwitch/Ceedling/blob/master/docs/SECURITY.md
+[security-report]:  https://github.com/ThrowTheSwitch/Ceedling/security/advisories/new
 
 <br/><br/>

data/docs/mkdocs/plugins/fff.md

@@ -4,7 +4,7 @@ This plugin causes Ceedling to use the [Fake Function Framework](https://github.
 
 Using _FFF_ provides less strict mocking than CMock and affords more loosely-coupled tests.
 
-This Ceedling 1.x plugin incorporates a snapshot of _FFF_ version 0.1.1 and supersedes a separately available [FFF Ceedling plugin project](https://github.com/ElectronVector/fake_function_framework). The built-in _FFF_ plugin that now comes with Ceedling was derived from the ElectronVector project and is now maintained along with Ceedling and tracks its updates.
+This Ceedling 1.x plugin incorporates a snapshot of _FFF_ version 1.1 and supersedes a separately available [FFF Ceedling plugin project](https://github.com/ElectronVector/fake_function_framework). The built-in _FFF_ plugin that now comes with Ceedling was derived from the ElectronVector project and is now maintained along with Ceedling and tracks its updates.
 
 !!! note "Special thanks to Matt Chernosky"
     [Matt Chernosky](http://www.electronvector.com) originally developed this plugin 

data/docs/mkdocs/plugins/gcov/gcovr.md

@@ -27,9 +27,14 @@ GCovr can be configured in two ways:
     CLI arguments. You must provide any settings that would have been provided 
     by the Gcov plugin.
 
-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).
+A Gcovr config file replaces Ceedling's own automatically generated exclusion
+patterns (see [Results filtering](#results-filtering) below) entirely — it is
+the only way to override or remove one of those defaults, since the
+project-configuration `:report_exclude` 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).
 
 ```ini
 ; You will need to revise these example exclude patterns to match your
@@ -45,6 +50,99 @@ exclude = .*test.*/test_.+\.c$
 exclude = .*build/.+\.c$
 ```
 
+## Results filtering
+
+By default, this plugin configures `gcovr` to excludes three categories of 
+`.c` 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.
+
+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.
+
+1.  **Test files** — matched by `:test_file_prefix` within your configured
+    `:paths` ↳ `:test` directories.
+
+    Given `:test_file_prefix` ⇒ `test_` and a `:paths` ↳ `:test` entry of
+    `test/`:
+
+    ```
+    .*test/.*/test_.+\.c$
+    ```
+
+2.  **Test support files** — any `.c` file within your configured `:paths` ↳
+    `:support` directories, regardless of name. Helpers, stubs, and fixtures
+    living there are no more production code than the test files themselves.
+
+    Given a `:paths` ↳ `:support` entry of `test/support/`:
+
+    ```
+    .*test/support/.+\.c$
+    ```
+
+3.  **Generated and vendored files** — any `.c` file anywhere below your
+    `:build_root`: 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 `.c` extension
+    regardless of your project's own `:extension` ↳ `:source` setting, since
+    every file it catches is one Ceedling itself writes in plain C.
+
+    Given `:build_root` ⇒ `build/`:
+
+    ```
+    .*build/.+\.c$
+    ```
+
+These patterns are generated automatically and combined with whatever you
+provide via [`:report_exclude`](#report_exclude) below.
+
+!!! warning "Not applied when using a Gcovr configuration file"
+    These defaults are only generated when Ceedling builds `gcovr`'s command
+    line directly. As covered in
+    [Gcovr configuration file](#gcovr-configuration-file) above, setting
+    `:config_file` bypasses this entirely — none of the three patterns above
+    are applied, and you must supply equivalent exclusions in the config file
+    yourself.
+
+### Overriding the defaults
+
+[`:report_exclude`](#report_exclude) can only add exclusions on top of the
+three defaults above — `gcovr --exclude` 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
+[`:report_include`](#report_include) 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.
+
+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
+[Gcovr configuration file](#gcovr-configuration-file). Setting `:config_file`
+stops Ceedling from generating any of the three patterns at all, handing you
+full control:
+
+```ini
+; gcovr.cfg — omits the test-file exclude pattern so test files remain in
+; coverage results, while still keeping generated/vendored build output out.
+exclude = .*build/.+\.c$
+```
+
+```yaml
+:gcov:
+  :gcovr:
+    :config_file: gcovr.cfg
+```
+
+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.
+
 ## Plugin configuration
 
 The following options are exposed through your project configuration file, all
@@ -198,6 +296,13 @@ is in addition to any other configured reports. (`gcovr --print-summary`)
 Keep only source files that match this filter. Filters are regular
 expressions. (`gcovr --filter`)
 
+This narrows which files are considered at all, but does not override
+[Results filtering](#results-filtering)'s automatic exclusion defaults — a
+file excluded by one of those three default patterns stays excluded even if
+it also matches `:report_include`. See
+[Overriding the defaults](#overriding-the-defaults) if you need to remove one
+of them.
+
 **Example:** `"^src"`
 
 ---
@@ -207,6 +312,15 @@ expressions. (`gcovr --filter`)
 Exclude source files that match this filter. Filters are regular expressions.
 (`gcovr --exclude`)
 
+Ceedling automatically generates and prepends its own exclusion patterns for
+test files, test support files, and generated/vendored build files — see
+[Results filtering](#results-filtering) 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 [Overriding the defaults](#overriding-the-defaults) for how to do 
+that instead.
+
 **Example:** `"^vendor.*|^build.*|^test.*|^lib.*"`
 
 ---

data/docs/mkdocs/plugins/gcov/reportgenerator.md

@@ -20,6 +20,99 @@ All generated reports are found in `<build root>/artifacts/gcov/ReportGenerator/
       - "-title:MyProject"
 ```
 
+## Results filtering
+
+This plugin filters coverage results for `reportgenerator` coverage reporting
+in two separate stages, each with its own defaults.
+
+### Coverage generation filtering
+
+Before `reportgenerator` ever runs, this plugin runs `gcov` itself against each
+`.gcno` file produced by the coverage test build, skipping any that match an 
+exclusion pattern — no `.gcov` data is ever produced for a skipped file, so 
+nothing downstream can put it back into a report.
+
+By default this skips:
+
+- **Test files** — matched by `:test_file_prefix`.
+- **Mocks** — matched by `:mock_prefix`.
+- **Test runners** — any filename containing `_runner`.
+- **Vendored Unity and CMock sources** — `unity.gcno` and `cmock.gcno` by
+  name.
+
+Given `:test_file_prefix` ⇒ `test_` and CMock's default `:mock_prefix` ⇒
+`Mock`, the equivalent filename-fragment patterns are:
+
+```
+test_[^\/\\]*
+Mock[^\/\\]*
+[^\/\\]*_runner[^\/\\]*
+unity
+cmock
+```
+
+These combine with whatever you add via [`:gcov_exclude`](#gcov_exclude)
+below. Your patterns extend this list, they don't replace it.
+
+### Report filtering
+
+Separately, once `.gcov` files exist, ReportGenerator's own `-filefilters:`
+argument controls which of them actually appear in the generated report(s).
+By default this excludes:
+
+1.  **Test paths** — every file anywhere under each of your configured
+    `:paths` ↳ `:test` directories, not only files matching
+    `:test_file_prefix`. A support subdirectory nested under a test path
+    (e.g. `test/support/`) is excluded as a side effect of this — the whole
+    tree goes, not just prefixed test files.
+
+    Given a `:paths` ↳ `:test` entry of `test/`:
+    ```
+    -./test/**/*
+    ```
+
+1.  **The build root** — every generated and vendored file: mocks, test
+    runners, Partials output, Unity, CMock, CException.
+
+    Given `:build_root` ⇒ `build/`:
+    ```
+    -./build/**/*
+    ```
+
+1.  **Partial-generated files** — only when `:use_partials` is enabled, any
+    file whose name starts with Ceedling's Partial filename prefix, wherever
+    it's found (not only under the build root).
+
+    ```
+    -ceedling_partial_*
+    ```
+
+These patterns are generated automatically and placed ahead of whatever you
+provide via [`:file_filters`](#file_filters) below.
+
+### Overriding the defaults
+
+Neither filtering stage above can be overridden or narrowed by plugin
+configuration — only added to.
+
+For [coverage generation filtering](#coverage-generation-filtering),
+[`:gcov_exclude`](#gcov_exclude) only ever adds more exclusion patterns; there
+is no plugin option to disable one of the built-in exclusions, and no way to
+resurrect `.gcov` data for a file `gcov` was never run against in the first
+place.
+
+For [report filtering](#report-filtering), the natural instinct is to reach
+for [`:custom_args`](#custom_args) to pass a second, conflicting
+`-filefilters:` argument, but this is not an option because of ReportGenerator's
+rules and the order in which the filters are provided by the plugin.
+
+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 [Gcovr option for this pluing](gcovr.md) instead. Its
+`:config_file` option hands full control to a `gcovr` configuration file,
+bypassing Ceedling's generated exclusions entirely (see
+[Gcovr's Results filtering](gcovr.md#results-filtering)).
+
 ## Plugin configuration
 
 ### `:history_directory`
@@ -62,10 +155,16 @@ filters. Wildcards are allowed, but not regular expressions.
 
 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.
+filters regardless of order. Wildcards are allowed, but not regular
+expressions.
+
+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
+[Report filtering](#report-filtering) 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 [Overriding the defaults](#overriding-the-defaults) above.
 
 **Example:** `"-./vendor/*;-./build/*;-./test/*;-./lib/*;+./src/*"`
 
@@ -94,6 +193,13 @@ Optional list of one or more regular expressions to exclude gcov notes
 files are never run through `gcov` at all. A trailing `.gcov` or `.gcno`
 suffix on a pattern is stripped automatically, so either form works.
 
+Ceedling combines your patterns with exclusions it generates automatically
+for test files, mocks, test runners, and vendored Unity/CMock sources (see
+[Coverage generation filtering](#coverage-generation-filtering) 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
+[Overriding the defaults](#overriding-the-defaults) above.
+
 ```yaml
 :gcov:
   :report_generator:

data/lib/ceedling/c_extractor/c_extractor_preprocessing.rb

@@ -246,7 +246,10 @@ class CExtractorPreprocessing
       # literal run -- it has to be seen and dispatched on its own below, before
       # any '"' or "'" inside the comment's own text gets mistaken for the start
       # of a string/char literal (see the // and /* branches for why that matters).
-      text << (scanner.scan(/[^"'\\\n\/]*/) || '')
+      # '#' is excluded the same way, so a #/## operator is seen and dispatched on
+      # its own below rather than absorbed into this run along with whatever
+      # whitespace happens to surround it (see the ## and # branches for why).
+      text << (scanner.scan(/[^"'\\\n\/#]*/) || '')
 
       if scanner.scan(%r{//})
         # A trailing line comment (e.g. "// don't change this") can contain an
@@ -280,6 +283,31 @@ class CExtractorPreprocessing
       elsif scanner.scan(%r{/})
         text << '/'
 
+      elsif scanner.scan(/##/)
+        # The C standard specifies ##'s token-paste semantics but not the exact
+        # whitespace a preprocessor emits when reconstructing macro text -- real
+        # toolchains can and do disagree here, and Ceedling regenerates this text
+        # into partials rather than promising byte-for-byte reproduction of that
+        # spacing. Discard whatever immediately follows the operator in the source,
+        # so its right-hand operand always glues on directly. The left side only
+        # trims when a word character (the operand actually being pasted) is
+        # immediately adjacent -- a lookbehind, not a blind rstrip -- so unrelated
+        # punctuation spacing that happens to precede the operator (e.g. the space
+        # after a macro argument's comma, or after the parameter list's closing
+        # paren when the replacement list itself starts with the operator) is left
+        # alone; that space was never the preprocessor-reconstruction artifact this
+        # is defending against. ## checked before bare '#' below so a real paste
+        # operator is never split into two stringize matches.
+        text.sub!(/(?<=\w)[ \t]+\z/, '')
+        scanner.scan(/[ \t]*/)
+        text << '##'
+
+      elsif scanner.scan(/#/)
+        # Same rationale as ## above, for the stringize operator.
+        text.sub!(/(?<=\w)[ \t]+\z/, '')
+        scanner.scan(/[ \t]*/)
+        text << '#'
+
       elsif (ch = scanner.peek(1)) == '"' || ch == "'"
         before = scanner.pos
         @c_extractor_code_text.skip_c_string(scanner, ch)

data/lib/ceedling/file_path_utils.rb

@@ -124,6 +124,10 @@ class FilePathUtils
     pairs = paths.map { |p| [p, p.gsub('\\', '/').chomp('/')] }
 
     # Sort shallowest-first so ancestors are always encountered before their descendants.
+    # No tiebreaker for same-depth entries needed: Ruby's sort_by doesn't guarantee a
+    # stable order among ties, but two same-depth paths can never be each other's
+    # ancestor, so the ancestor-exclusion check below is correct regardless of which
+    # order same-depth ties come out in.
     pairs.sort_by! { |_, normalized| normalized.count('/') }
 
     kept = []

data/lib/ceedling/generators/generator.rb

@@ -40,17 +40,19 @@ class Generator
   # rather than duplicated by generate_partial_implementation and generate_partial_interface.
   # Returns the bare generated filename (for the caller to add to each header's own includes
   # list) or nil when the module has no typedefs or aggregate definitions to share.
-  def generate_partial_types(name:, c_module:, output_path:)
+  def generate_partial_types(name:, c_module:, output_path:, includes: [], include_guard: nil)
     arg_hash = {
       :name => name,
       :c_module => c_module,
-      :output_path => output_path
+      :output_path => output_path,
+      :includes => includes,
+      :include_guard => include_guard
     }
 
     return @generator_partials.generate_types( **arg_hash )
   end
 
-  def generate_partial_interface(test:, partial:, function_declarations:, includes:, c_module:, input_filepath:, output_path:)
+  def generate_partial_interface(test:, partial:, function_declarations:, includes:, c_module:, input_filepath:, output_path:, include_guard: nil)
     msg = @reportinator.generate_module_progress(
       operation: "Generating Partial mockable interface for",
       module_name: test,
@@ -64,7 +66,8 @@ class Generator
       :function_declarations => function_declarations,
       :includes => includes,
       :c_module => c_module,
-      :output_path => output_path
+      :output_path => output_path,
+      :include_guard => include_guard
     }
 
     return @generator_partials.generate_interface( **arg_hash )
@@ -78,7 +81,8 @@ class Generator
       header_includes:,
       c_module:,
       input_filepath:,
-      output_path:
+      output_path:,
+      include_guard: nil
     )
 
     msg = @reportinator.generate_module_progress(
@@ -95,7 +99,8 @@ class Generator
       :source_includes => source_includes,
       :header_includes => header_includes,
       :c_module => c_module,
-      :output_path => output_path
+      :output_path => output_path,
+      :include_guard => include_guard
     }
 
     return @generator_partials.generate_implementation( **arg_hash )