ceedling 1.1.9 → 1.2.0

data/docs/KnownIssues.md

@@ -10,20 +10,54 @@ Known issues are complemented by three other documents:
 
 ## All versions
 
-- Ceedling installation as a gem (variations of `gem install ceedling`) can fail if installation is allowed to run the default step of RDoc scanning. **Always use `--no-document` to opt out of the RDoc tool’s code scanning during Ceedling installation.** This documentation step is not needed by a user, and, more importantly, RDoc can cause installation failures due to bugs or language incompatibilities in RDoc’s custom language parser. The prepackaged _MadScienceLab_ Docker images avoid this issue entirely.
+- Ceedling installation as a gem (variations of `gem install ceedling`) can fail if installation is allowed to run the default step of RDoc scanning. **Always use `--no-document` to opt out of the RDoc tool’s code scanning during Ceedling installation.** This documentation step is not needed by a Ceedling user, and, more importantly, RDoc can cause installation failures due to bugs or language incompatibilities in RDoc’s custom Ruby language parser. The prepackaged _MadScienceLab_ Docker images avoid this issue entirely.
 
 ---
 
-## 1.1.0 — 2026-07-16
+## 1.2.0 — 2026-10-21
+
+Ceedling 1.2.0 requires Ruby 3+ but only unoficially supports Ruby 4.
+
+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. Delta builds (as of 1.2.0) offer considerable build time savings as do the speedup gains due to parallelization as of 1.0.0. Future releases will optimize away duplication of build steps.
+1. An `#include` directive must resolve to a file within your project's configured `:paths` search collection. A path that would resolve outside your configured search paths (e.g. via relative paths beyond search paths or excessive `..` parent-directory segments) is now rejected with a clear, specific error rather than silently causing a confusing downstream build failure.
+1. With test preprocessing enabled, a test file’s `#include` of a mock whose name comes from a macro defined only in a header, as in `#include MOCK_HEADER` with `MOCK_HEADER` defined in another header, cannot be found. Define the macro under `:defines` ↳ `:test` so the test file sees it directly.
+1. Fallback preprocessing remains a best effort with no guarantees. It is used where your toolchain’s preprocessor does not support `-fdirectives-only` or where you force it with `:test_build` ↳ `:preprocess_force_fallback`. Its handling of conditional compilation is limited and may not resolve the same branches your compiler would. Macro expansion is not supported at all.
+1. Paths for `TEST_SOURCE_FILE(...)` remain relative to **_project root_** — that is, from where you execute `ceedling` at the command line. If you move source files or change your directory structure, `TEST_SOURCE_FILE(...)` calls referencing moved files will need to be updated.
+
+### Partials
+
+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 type created by a macro invocation rather than written out — the list and queue building macros in `sys/queue.h`, for instance — is not recognized as a type, and a Partial using one fails to compile with an `unknown type name` error.
+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. Partials cannot generate a module that text-only fallback preprocessing is unable to resolve — a module with an `#include` naming a macro, or with a type behind a conditional expression that cannot be evaluated without a real preprocessor. Ceedling stops the build and names the file and line rather than generating something subtly wrong. Fallback preprocessing is only used where your compiler does not support `-fdirectives-only`, older Apple Clang releases most notably, or where you force it with `:test_build` ↳ `:preprocess_force_fallback`.
+
+## 1.1.x — 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. 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.
+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 1.2.0.
+1. On Windows, a test file whose name contains _install_, _setup_, _update_, or _patch_ can build a test executable that the Installer Detection feature of User Account Control (UAC) will not run without administrator privileges. Toolchains that embed a manifest requesting the invoker’s privileges, such as MSYS2’s MinGW-w64 GCC with its default manifest installed, avoid this. Otherwise, avoid these words in test filenames.
+1. Ceedling depends on the `erb` gem. Published `erb` versions include those affected by CVE-2026-41316, a flaw in how ERB reconstructs a template object from serialized data. Ceedling never reconstructs a template object this way, so Ceedling itself is not exposed. Dependency and security scanners may still flag the `erb` gem because the dependency is present. The `erb` dependency will be removed entirely as of 1.2.0 for multiple reasons beyond resolving the security issue.
+
+### Partials
+
+1. Enabling Partials blanket overrides your project `:cmock` ↳ `:treat_inlines` setting to prevent duplicated file generation work. This override prevents this feature from being used with traditional mocks as you might desire. This will be addressed in 1.2.0.
+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 type created by a macro invocation rather than written out — the list and queue building macros in `sys/queue.h`, for instance — is not recognized as a type, and a Partial using one fails to compile with an `unknown type name` error.
+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. A source line can be joined to the line before it in a generated Partial when its line number happens to match the last line of a header the source included. Two adjacent `#define`s, for instance, become one line, and the build fails with `stray '#' in program`.
 
 ---
 
@@ -37,3 +71,4 @@ Known issues are complemented by three other documents:
 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. Ceedling’s many test preprocessing improvements are not presently able to preserve Unity’s special `TEST_CASE()` and `TEST_RANGE()` features. However, preprocessing of test files is much less frequently needed than preprocessing of mockable header files. Test preprocessing can now be configured to enable only one or the other. As such, these advanced Unity features can still be used in even sophisticated projects.
 1. The Bullseye code coverage plugin has been temporarily disabled until a license can be procured that will allow updates and improvements.
+1. On Windows, a test file whose name contains _install_, _setup_, _update_, or _patch_ can build a test executable that the Installer Detection feature of User Account Control (UAC) will not run without administrator privileges. Toolchains that embed a manifest requesting the invoker’s privileges, such as MSYS2’s MinGW-w64 GCC with its default manifest installed, avoid this. Otherwise, avoid these words in test filenames.

data/docs/ReleaseNotes.md

@@ -8,6 +8,282 @@ These release notes are complemented by three other documents:
 
 ---
 
+# 1.2.0 — October 21, 2026
+
+## 👀 Highlights
+
+1.2.0 restores delta builds, adds full handling of paths and same-named files, is faster than 1.1.0, and incorporates a large number of fixes and other improvements. See [Changelog](Changelog.md) for a full list of new features, bug fixes, and improvements.
+
+The incomplete list of goodies:
+
+* **Delta builds** are back. A build only regenerates, compiles, links, or reruns what changed files require. Delta builds are automatic and complement parallel builds for build time speedups.
+* Full support for **relative paths and same-named files**. `#include` directives, `TEST_SOURCE_FILE()`, test task names (e.g. `ceedling test:foo/file` vs. `ceedling test:bar/file`), and [Partials][partials-directory-docs-1.2.0] can all distinguish files and modules of the same name by path.
+* **Multiple file extensions per file type**, so `.c` and `.cc` sources, for instance, can be collected into one build.
+* **Shuffled test order** through Unity’s randomized test case ordering. When test shuffling is enabled, delta builds always rerun test executables so each run is shuffled.
+* `TEST_SOURCE_FILE()` can now **remove** a source file from a test executable, overriding Ceedling’s source file conventions where a project’s structure differs from the convention’s assumptions.
+* Plugins:
+   * The [Gcov plugin][gcov-plugin-1.2.0] adds raw `gcovr` arguments and `ReportGenerator` coverage thresholds.
+   * The [Valgrind][valgrind-plugin-1.2.0] and [Cppcheck][cppcheck-plugin-1.2.0] plugins have expanded features including failing a build on analysis findings.
+   * The new [Sanitize plugin][sanitize-plugin-1.2.0] builds and runs tests with ASan, UBSan, and LeakSanitizer, naming each finding where a test fails and writing text, JSON, and SARIF reports.
+   * The [Bullseye code coverage plugin][bullseye-plugin-1.2.0] is re-enabled and modernized (disabled since 1.0.0), adding branch coverage detail, XML reports, and a coverage threshold.
+* Performance improvements yield a 5–10% faster build even before delta builds speed up successive runs.
+* `ceedling.yml` is accepted as an alternate default project filename alongside `project.yml`.
+* `ceedling dumpconfig --stdout` writes the fully resolved project configuration to the console (useful for scripting and agentic tools).
+* Some 40+ fixes and refinements for robustness across test preprocessing, Partials, mocking, backtraces, mixins, filepath handling, and plugin reports.
+
+[partials-directory-docs-1.2.0]: https://docs.throwtheswitch.org/Ceedling/1.2.0/testing-guide/partials/directives/#naming-a-module-by-directory
+[bullseye-plugin-1.2.0]: https://docs.throwtheswitch.org/Ceedling/1.2.0/plugins/bullseye/
+[sanitize-plugin-1.2.0]: https://docs.throwtheswitch.org/Ceedling/1.2.0/plugins/sanitize/
+[gcov-plugin-1.2.0]: https://docs.throwtheswitch.org/Ceedling/1.2.0/plugins/gcov/
+[valgrind-plugin-1.2.0]: https://docs.throwtheswitch.org/Ceedling/1.2.0/plugins/valgrind/
+[cppcheck-plugin-1.2.0]: https://docs.throwtheswitch.org/Ceedling/1.2.0/plugins/cppcheck/
+
+## 🔢 Ruby version support
+
+Ceedling 1.2.0 is known to work well across all versions of Ruby 3.0 – 3.4 on Linux, Windows, and macOS. Ruby 2.x support was removed with 1.0.0.
+
+Ceedling 1.2.0 also passes all internal tests for Ruby 3.5, but it has not yet been thoroughly exercised with Ruby 3.5 in the real world.
+
+Ceedling 1.2.0 has had no Ruby 4.0 compatibility work, but users have reported success running Ceedling with Ruby 4.0.
+
+## 📖 Configuration Cheatsheet for 1.2.0 Changes
+
+The following is not a complete project configuration. But, for those already familiar with Ceedling, this cheatsheet illustrates some of the important changes in this latest release of Ceedling through the lens of a project configuration. To be clear, more has changed than what is referenced in this YAML blurb (see the Changelog).
+
+```yaml
+:extension:
+  # Each file type now accepts a single extension or a list of extensions.
+  # Ceedling collects files under any extension in a list.
+  :source:
+    - .c
+    - .C
+    - .cc
+  :header: .h
+
+:unity:
+  # When TRUE, Unity's test runner shuffles the order of test cases within each test executable.
+  # Useful for surfacing tests that depend on execution order or on state left by an earlier test.
+  # Delta builds always rerun test executables when shuffling is enabled so each run is shuffled.
+  :shuffle_tests: FALSE
+
+:test_runner:
+  # Seed for :shuffle_tests. The default of 0 seeds from the current time for a new order
+  # on every run. A fixed, nonzero value repeats one shuffled order (e.g. for debugging).
+  :rng_seed: 0
+
+:plugins:
+  :enabled:
+    # (See config blurbs below)
+    - gcov
+    - bullseye
+    - valgrind
+    - sanitize
+    - cppcheck
+    - module_generator
+    - dependencies
+    - report_build_warnings_log
+    - report_tests_log_factory
+
+    # Enable only one console test report plugin
+    - report_tests_ide_stdout
+    # - report_tests_gtestlike_stdout
+
+:gcov:
+  # gcovr now also generates JaCoCo XML and LCOV reports (requires gcovr 7.0+).
+  # ReportGenerator continues to generate lcov as well.
+  :reports:
+    - JaCoCo
+    - lcov
+
+  :gcovr:
+    # Optional list of raw command line arguments passed to gcovr as-is (e.g. limiting
+    # its search paths). These are passed even when :config_file is set.
+    :custom_args: []
+
+    # Optional JaCoCo and LCOV report settings
+    :jacoco_pretty: FALSE
+    :jacoco_artifact_filename: GcovCoverageJaCoCo.xml
+    :lcov_comment: "Q-36 Space Modulator"
+    :lcov_test_name: unit_tests
+    :lcov_artifact_filename: GcovCoverage.lcov
+
+  :report_generator:
+    # Optional coverage thresholds (1–100) that break the build, mirroring the gcovr
+    # :fail_under_* options already available.
+    :fail_under_line: 80
+    :fail_under_branch: 70
+    :fail_under_method: 90
+    :fail_under_full_method: 75
+
+# The Bullseye code coverage plugin is enabled again (disabled since 1.0.0) and modernized.
+:bullseye:
+  # Coverage totals and per-source function coverage printed to the console after tests
+  :summaries: TRUE
+
+  # Untested sources are logged by default.
+  # - :list (default) logs sources missing from coverage results.
+  # - :ignore entirely omits any handling of untested sources.
+  # - :compile compiles all untested sources for 0% coverage entries.
+  :untested_sources: :list
+
+  # Optional annotated listing of branches: :none (default), :uncovered, or :all
+  :branch_detail: :none
+
+  # Optional machine-readable coverage report: :none (default), :native, or :cobertura
+  :xml_report: :none
+
+  # Optional coverage thresholds that break the build. 0 (default) disables each check.
+  :fail_under:
+    :functions: 0
+    :branches: 0
+
+  # Path to a floating-license manager file. Not needed for node-locked licenses.
+  :license_manager_file: ~
+
+:valgrind:
+  # When TRUE, writes a machine-readable XML report per test binary alongside the text log.
+  # With XML enabled, memory errors that are reported by the plugin or optionally cause
+  # a test build to break are counted from the XML rather than the text log (more reliable).
+  :xml_report: FALSE
+
+  # Valgrind suppression files, each passed as one --suppressions= argument ahead of
+  # any entries in :arguments.
+  :suppressions: []
+
+# New plugin: builds and runs tests with sanitizers in sanitize: builds of their own.
+# Its flags never reach another plugin's build, such as gcov: or valgrind:.
+:sanitize:
+  # Any of :address, :undefined, and :leak. ASan's runtime checks leaks too.
+  :sanitizers:
+    - :address
+    - :undefined
+
+  # Halt each test at its first finding (default), or keep running after each
+  :recover: FALSE
+
+  # Check for leaks at exit (Linux only; left off on macOS)
+  :detect_leaks: TRUE
+
+  # Also instrument ordinary test: builds
+  :test_builds: FALSE
+
+  # Fail the build on any finding
+  :fail_build: TRUE
+
+  # Any of :text, :json, and :sarif. None listed is the text report alone.
+  :reports:
+    - :sarif
+
+  # Optional extra runtime options for each sanitizer
+  :runtime_options:
+    :asan:
+      - strict_string_checks=1
+
+:cppcheck:
+  # When TRUE, findings matching :fail_build_severities fail the build.
+  # Enabling this implies the XML report, since findings are counted from its output.
+  :fail_build: FALSE
+
+  # Finding severities that fail the build when :fail_build is enabled.
+  # Valid values: error, warning, style, performance, portability, information.
+  :fail_build_severities:
+    - error
+
+  # The default XML report schema version is now 2, which every Cppcheck release accepts.
+  # Older Cppcheck releases reject version 3 and fail the build.
+  :xml_report_version: 2
+
+:module_generator:
+  # :naming now takes effect (bug fix). Without it, generated file names keep the case
+  # typed at the command line (it no longer defaults to :snake).
+  # Options: :bumpy, :camel, :snake, or :caps.
+  :naming: :snake
+
+  # Wrap each generated test file in #if rather than the default #ifdef.
+  # Options: :ifdef (default) or :if.
+  :test_guard: :if
+
+:dependencies:
+  :deps:
+    - :name: Packer
+      :paths:
+        :fetch: third_party/packer
+        :build: third_party/packer/build
+
+        # New optional folder where `dependencies:deploy` copies executables and
+        # dynamic libraries. Defaults to beside the release executable.
+        :deploy: tools/bin
+      :fetch:
+        :method: :git
+        :source: https://github.com/example/firmware-packer.git
+        :tag: v1.3.0
+      :build:
+        - make all BUILD=build
+      :artifacts:
+        # New list of programs a dependency builds as tools rather than libraries.
+        # They are built for a release, never linked, and copied by `dependencies:deploy`.
+        :executables:
+          - packer
+
+:report_build_warnings_log:
+  # Now a base name. Each report adds its own extension (e.g. warnings.log, warnings.sarif).
+  :filename: warnings
+
+  # Any of :text, :sarif, and :json. No listing is the original text log alone (default).
+  :reports:
+    - :text
+    - :sarif
+
+  # Optional regular expressions replacing the default match of any line mentioning "warning"
+  :patterns: []
+
+  # Optional regular expressions dropping matched warnings, along with their context
+  :excludes:
+    - 'third_party/'
+
+:report_tests_log_factory:
+  :reports:
+    - junit
+  :junit:
+    # Each JUnit <testcase> now carries classname, file, and line attributes.
+    # When TRUE, the file attribute is written as path#line for tools that follow that form.
+    :file_line_anchor: FALSE
+
+:report_tests_ide_stdout:
+  # Failed and ignored tests now print as GCC diagnostics by default, which IDEs read as problems.
+  # - :gcc (default) works with any tool that reads GCC output.
+  # - :legacy restores the lines printed before 1.2.0.
+  # - :vscode, :eclipse, and :clion are shortcuts for the :gcc settings each IDE needs.
+  :format: :gcc
+
+  # Optional full paths in place of project-relative paths. Unset, each format's own
+  # path form applies. :clion requires TRUE and automatically sets this value.
+  :absolute_paths: FALSE
+
+:report_tests_gtestlike_stdout:
+  # Unity ignored tests are now reported as GoogleTest skipped tests.
+  # Set FALSE to leave ignored tests out of the report.
+  :ignored_as_skipped: TRUE
+
+```
+
+## 📣 Shout-outs and Special Thank-You’s
+
+### Sponsors
+
+  - [ThingamaByte, LLC](https://thingamabyte.com) - For continuing to nurture these projects and community with so much of their time.
+
+### Major Code/Doc Contributors
+
+These individuals contributed significant features, bugfixes, and improvements.
+
+  - Michael Karlesky
+  - Mark VanderVoord
+
+### Also, thanks for your contributions!
+
+James Raphael Tiovalen, Kamil Sroka
+
 # 1.1.0 — July 16, 2026
 
 ## 👀 Highlights
@@ -30,21 +306,21 @@ The incomplete list of goodies:
 * Integrates latest [Unity](https://github.com/ThrowTheSwitch/Unity) ([2.7.0](https://github.com/ThrowTheSwitch/Unity/blob/master/docs/UnityChangeLog.md)).
 * Integrates latest [CMock](https://github.com/ThrowTheSwitch/CMock) ([2.7.0](https://github.com/ThrowTheSwitch/CMock/blob/master/docs/CMockChangeLog.md)).
 
-[partials-docs]: https://throwtheswitch.github.io/Ceedling/1.1.0/testing-guide/partials/
-[example-projects]: https://throwtheswitch.github.io/Ceedling/latest/getting-started/example-projects/
-[ceedling-docs-site]: https://throwtheswitch.github.io/Ceedling/
-[valgrind-plugin]: https://throwtheswitch.github.io/Ceedling/1.1.0/plugins/valgrind/
-[cppcheck-plugin]: https://throwtheswitch.github.io/Ceedling/1.1.0/plugins/cppcheck/
-[gcov-plugin]: https://throwtheswitch.github.io/Ceedling/1.1.0/plugins/gcov/
-[mixins-inline-yaml]: https://throwtheswitch.github.io/Ceedling/latest/configuration/mixins/?h=mixins#-mixin-command-line-flags
+[partials-docs]: https://docs.throwtheswitch.org/Ceedling/1.1.0/testing-guide/partials/
+[example-projects]: https://docs.throwtheswitch.org/Ceedling/latest/getting-started/example-projects/
+[ceedling-docs-site]: https://docs.throwtheswitch.org/Ceedling/
+[valgrind-plugin]: https://docs.throwtheswitch.org/Ceedling/1.1.0/plugins/valgrind/
+[cppcheck-plugin]: https://docs.throwtheswitch.org/Ceedling/1.1.0/plugins/cppcheck/
+[gcov-plugin]: https://docs.throwtheswitch.org/Ceedling/1.1.0/plugins/gcov/
+[mixins-inline-yaml]: https://docs.throwtheswitch.org/Ceedling/latest/configuration/mixins/?h=mixins#-mixin-command-line-flags
 
 ## 🔢 Ruby version support
 
-Ceedling 1.1.0 is known to work well across all versions of Ruby 3.0 – 3.4 on Linux, Windows, and macOS. Ruby 2.x support was removed with 1.1.0.
+Ceedling 1.1.0 is known to work well across all versions of Ruby 3.0 – 3.4 on Linux, Windows, and macOS. Ruby 2.x support was removed with 1.0.0.
 
 Ceedling 1.1.0 also passes all internal tests for Ruby 3.5, but it has not yet been thoroughly exercised with Ruby 3.5 in the real world.
 
-To avoid Ruby version and installation environment complications, consider using [the readymade MadScienceLab Docker images](https://throwtheswitch.github.io/Ceedling/1.1.0/getting-started/installation/#madsciencelab-docker-images).
+To avoid Ruby version and installation environment complications, consider using [the readymade MadScienceLab Docker images](https://docs.throwtheswitch.org/Ceedling/1.1.0/getting-started/installation/#madsciencelab-docker-images).
 
 ## 📖 Configuration Cheatsheet for 1.1.0 Changes
 
@@ -165,9 +441,9 @@ We'd like to make some quick shout-outs to some especially helpful contributions
 ### Sponsors of Ceedling 1.0.0
 
  - [ThingamaByte, LLC](https://thingamabyte.com) - For continuing to nurture these projects and community with so much of their time.
- - [Kamstrup, A/S](https://kamstrup.com) - For sponsoring and testing Ceedling's new parallel build/test support
- - [Fraunhofer Institute for Integrated Systems and Device Technology IISB](https://iisb.fraunhofer.de) - For also sponsoring and testing Ceedling's new parallel build/test support
- - [Peter Membrey](https://github.com/pmembrey) - For sponsoring, helping to plan, and validating Ceedling's new dependencies plugin
+ - [Kamstrup, A/S](https://kamstrup.com) - For sponsoring and testing Ceedling’s new parallel build/test support
+ - [Fraunhofer Institute for Integrated Systems and Device Technology IISB](https://iisb.fraunhofer.de) - For also sponsoring and testing Ceedling’s new parallel build/test support
+ - [Peter Membrey](https://github.com/pmembrey) - For sponsoring, helping to plan, and validating Ceedling’s new dependencies plugin
 
 ### Major Code/Doc Contributors 
 

data/docs/SECURITY.md

@@ -3,10 +3,82 @@
 This document outlines security procedures and general policies for all `ThrowTheSwitch.org`
 projects, including `Unity`, `CMock`, and `Ceedling`.
 
+  * [Supported Versions](#supported-versions)
+  * [Software Bill of Materials](#software-bill-of-materials)
+  * [Automated Security Scanner False Positives](#automated-security-scanner-false-positives)
   * [Reporting a Bug](#reporting-a-bug)
   * [Disclosure Policy](#disclosure-policy)
   * [Comments on this Policy](#comments-on-this-policy)
 
+## Supported Versions
+
+For Ceedling, security fixes are made for two lines of development.
+
+| Version | Branch | Receives security fixes |
+|---|---|---|
+| Latest release | `master` | Yes |
+| Current pre-release | `next_version` | Yes |
+| Any earlier release | | No |
+
+The `master` branch contains the latest release and its bug fix patch 
+derivatives. `next_version` contains the development work for the next 
+minor or major release.
+
+If you use an earlier release, upgrade to the latest release to receive a fix.
+
+## Software Bill of Materials
+
+Ceedling publishes a [Software Bill of Materials with every release](https://docs.throwtheswitch.org/Ceedling/latest/project/sbom/).
+Use it to determine whether a given release is affected by a vulnerability in 
+something Ceedling ships or depends on.
+
+Each release carries two documents, one CycloneDX and one SPDX, attached beside
+the `.gem` file. Every component is identified by a Package URL (PURL). The 
+vendored C components are identified by the commit they are pinned at, which is 
+what distinguishes two copies of the same component at different commits.
+
+The documents describe the Ceedling gem as distributed. They do not describe the
+C code Ceedling builds, nor the external tools an enabled plugin requires. Those
+tools vary by installation and each plugin documents its own.
+
+Each document is signed against the gem it describes. Verification needs the
+predicate type named, because `gh attestation verify` looks for SLSA provenance
+by default.
+
+```
+gh attestation verify ceedling-<version>.gem \
+  --repo ThrowTheSwitch/Ceedling \
+  --predicate-type https://cyclonedx.org/bom
+```
+
+## 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 +91,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.
@@ -32,8 +114,8 @@ release process, involving the following steps:
 
   * Confirm the problem and determine the affected versions.
   * Audit code to find any potential similar problems.
-  * Prepare fixes for all releases still under maintenance. These fixes will be
-    released as fast as possible.
+  * Prepare fixes for all [supported versions](#supported-versions). These fixes
+    will be released as fast as possible.
 
 ## Comments on this Policy
 

data/docs/ThrowTheSwitchCodingStandard.md

@@ -160,7 +160,7 @@ catching an error and you have a one-line, go ahead and to it on the same line.
 ```C
     while (blah)
     {
-        //Like so. Even if only one line, we use braces.
+        /* Like so. Even if only one line, we use braces. */
     }
 ```
 
@@ -198,10 +198,28 @@ that happens, we like to indent further to line things up in nice tidy columns.
 - Constants - all upper case with underscores
 
 
+#### Linting
+
+Ceedling lints its Ruby with [RuboCop](https://rubocop.org). Its configuration in
+`.rubocop.yml` is the enforced part of this standard. It covers defects,
+complexity, security, and performance, leaving the style choices above to
+this document and to review.
+
+
 ## Documentation
 
-Egad. Really? We use markdown and we like pdf files because they can be made to
-look nice while still being portable. Good enough?
+We use Markdown. Ceedling builds its Markdown into a versioned
+documentation website with [MkDocs](https://www.mkdocs.org), published at
+[docs.throwtheswitch.org](https://docs.throwtheswitch.org/Ceedling/).
+
+These same Markdown files are also rendered into a bundle of HTML docs 
+locally navigable from your filesystem with your browser. The `ceedling` CLI 
+includes various options to export that local documentation bundle.
 
+The `docs/` directory of the project contains a handful of PDFs that predate
+the wide availability of better documentation options. The content of these 
+guides largely remains valuable if outdated because of changes to certain 
+features, conventions, or websites. New PDFs should not be generated. The 
+current set is preserved as an archive.
 
 *Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*

data/docs/overrides/main.html

@@ -0,0 +1,32 @@
+{% extends "base.html" %}
+
+{#
+  Material's own `outdated`/`announce` blocks (base.html) ship empty by
+  default -- both are opt-in via a project template override like this one.
+
+  `outdated`: the standard "you're not viewing the latest version" warning
+  banner. Material only renders its wrapping markup when this block actually
+  produces non-empty output, so suppressing it here for prerelease pages
+  (rather than just leaving the block's *content* blank) is what keeps the
+  banner from appearing at all on those pages.
+
+  `announce`: a separate announcement bar, used here to carry the prerelease
+  notice instead. `extra.prerelease` is set to `true` only in
+  mkdocs.prerelease.yml -- switching both blocks based on which mkdocs
+  config built the page.
+#}
+
+{% block outdated %}
+  {% if not config.extra.prerelease %}
+    You are not viewing the latest version.
+    <a href="{{ '../' ~ base_url }}">
+      <strong>Click here to go to latest.</strong>
+    </a>
+  {% endif %}
+{% endblock %}
+
+{% block announce %}
+  {% if config.extra.prerelease %}
+    This is prerelease documentation for an upcoming Ceedling release.
+  {% endif %}
+{% endblock %}

data/examples/temp_sensor/mixin/add_bullseye.yml

@@ -0,0 +1,19 @@
+# =========================================================================
+#   Ceedling - Test-Centered Build System for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2010-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
+---
+
+# Enable bullseye plugin
+:plugins:
+  :enabled:
+    - bullseye
+
+# Add -bullseye to the plugins list to make use of the bullseye plugin.
+# You will need a working Bullseye Coverage installation and license to make it work.
+# For more information on these options, see docs in docs/mkdocs/plugins/bullseye
+
+...

data/examples/wondrous_forest/README.md

@@ -33,6 +33,8 @@ wondrous_forest/
 │   ├── ForestMonitor.c/.h
 │   ├── SensorHal.c/.h
 │   ├── UartDriver.c/.h
+│   ├── sensors/soil/Calibration.c/.h   # Same module name as the one below
+│   ├── sensors/light/Calibration.c/.h  # Told apart by directory
 │   └── Types.h
 └── test/              # Test files — Using Partials and traditional assertions/mocks
     ├── TestTemperatureSensor.c
@@ -61,6 +63,7 @@ wondrous_forest/
 | TestForestMonitor.c     | `TEST_PARTIAL_PUBLIC_MODULE` + `MOCK_PARTIAL_PRIVATE_MODULE`  |
 | TestSensorHal.c         | Traditional — HAL has no private statics                      |
 | TestUartDriver.c        | Traditional — UART driver has no private statics              |
+| TestCalibration.c       | `TEST_PARTIAL_PRIVATE_MODULE_AT` — two same-named modules     |
 
 ---
 

data/examples/wondrous_forest/src/sensors/light/Calibration.c

@@ -0,0 +1,21 @@
+/* =========================================================================
+    Ceedling - Test-Centered Build System for C
+    ThrowTheSwitch.org
+    Copyright (c) 2010-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+    SPDX-License-Identifier: MIT
+========================================================================= */
+
+#include "sensors/light/Calibration.h"
+
+/* Private to this module -- see the soil sensor's own clamp. */
+static int Light__Clamp(int value)
+{
+  if (value < 0)    { return 0; }
+  if (value > 1023) { return 1023; }
+  return value;
+}
+
+int LightCalibration_Apply(int raw)
+{
+  return Light__Clamp(raw * 4);
+}