ceedling 1.0.0 → 1.1.0

data/bin/recursive_merger.rb

@@ -0,0 +1,128 @@
+# =========================================================================
+#   Ceedling - Test-Centered Build System for C
+#   ThrowTheSwitch.org
+#   Copyright (c) 2010-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   SPDX-License-Identifier: MIT
+# =========================================================================
+
+##
+## RecursiveMerger
+## ===============
+##
+## Merges a mixin hash into a base configuration hash, key by key, recursing
+## into nested hashes. The goal is for higher-priority mixin content to "win"
+## in a predictable way:
+##
+##   Single values (strings, numbers, symbols, booleans):
+##     The mixin value replaces the config value. Because mixins are merged in
+##     priority order — lowest first, highest last — the last mixin's single
+##     value is the one that sticks.
+##
+##   Lists (arrays):
+##     GENERAL RULE — the mixin's entries are placed BEFORE the config's
+##     entries in the combined list. This means higher-priority mixin entries
+##     appear earlier in the merged list. For example, when a command line
+##     mixin adds include search paths and a config file mixin also adds
+##     search paths, the command line paths come first and are searched first.
+##
+##     EXCEPTION — tool argument lists under the key path
+##     [:tools, <tool name>, :arguments] are APPENDED (mixin entries added
+##     at the END of the list). Compilers and linkers process arguments
+##     left-to-right, so a later occurrence of a flag like -O0 overrides an
+##     earlier -O2. Appending ensures that a higher-priority mixin's tool
+##     arguments still take effect.
+##
+##   Single value merged into a config list:
+##     The mixin's single value is wrapped in a one-element list and then
+##     placed BEFORE the config list entries, consistent with the general
+##     list rule above.
+##
+##   List merged into a config single value:
+##     The mixin's list replaces the config value outright. This is flagged
+##     as a type mismatch by validate_merge() before this method runs.
+##
+##   Hash merged into a config non-hash:
+##     The mixin's hash replaces the config value. Exception: if the config
+##     value is itself a list, the mixin hash is treated as a single value
+##     and prepended (consistent with single-value-into-list behavior).
+##
+##   Hash merged with a config hash:
+##     Recurse into both hashes at the matching key so each nested key is
+##     handled individually by the same rules.
+##
+## Usage
+## -----
+##   RecursiveMerger.merge!(config_hash, mixin_hash)
+##
+## The merge is destructive: config_hash is modified in place.
+##
+
+class RecursiveMerger
+
+  # Merge mixin into config in place. path is used internally to track the
+  # current key path for the tool-arguments exception check.
+  def self.merge!(config, mixin, path = [])
+    mixin.each do |key, mixin_val|
+      config_val   = config[key]
+      current_path = path + [key]
+
+      if mixin_val.is_a?(Hash) && config_val.is_a?(Hash)
+        # Both sides have a hash at this key — recurse so each nested key is
+        # handled individually rather than replacing the entire sub-hash.
+        merge!(config_val, mixin_val, current_path)
+
+      elsif config_val.is_a?(Array)
+        # Config already has a list at this key. Regardless of whether the
+        # mixin value is a list, a hash, or a single value, we keep the list
+        # and merge the mixin value into it.
+        if mixin_val.is_a?(Array)
+          # Both sides are lists.
+          if tool_arguments_path?(current_path)
+            # EXCEPTION: tool argument lists are extended at the end so that
+            # a later (higher-priority) flag overrides an earlier one when
+            # the compiler or linker processes arguments left-to-right.
+            config[key] = config_val + mixin_val
+          else
+            # GENERAL: prepend mixin entries so higher-priority content
+            # appears first in the combined list (e.g. include search paths).
+            config[key] = mixin_val + config_val
+          end
+        else
+          # Mixin has a single value (or hash treated as a value) where config
+          # has a list. Wrap the mixin value in a one-element list and prepend
+          # it so the mixin value appears first.
+          config[key] = [mixin_val] + config_val
+        end
+
+      elsif mixin_val.is_a?(Array)
+        # Mixin has a list where config has a single value (or nothing).
+        # Replace the config value with the mixin list.
+        # Note: validate_merge() flags this as an incompatible type change
+        # when the config key already exists with a non-array value.
+        config[key] = mixin_val
+
+      elsif mixin_val.is_a?(Hash)
+        # Mixin has a hash where config has a non-hash, non-array value (or
+        # the key is absent in config). Replace outright.
+        config[key] = mixin_val
+
+      else
+        # Both sides have single values — mixin replaces config.
+        # Because mixins are merged in lowest-to-highest-priority order,
+        # the last mixin to write a key wins.
+        config[key] = mixin_val
+      end
+    end
+  end
+
+  ### Private
+
+  private_class_method def self.tool_arguments_path?(path)
+    # Match exactly [:tools, <any tool name>, :arguments].
+    # The first element is :tools, the third is :arguments, and the middle
+    # element is the tool name (any symbol). Path length must be exactly 3
+    # so deeper nesting (e.g. inside :arguments) is not accidentally matched.
+    path.length == 3 && path[0] == :tools && path[2] == :arguments
+  end
+
+end

data/bin/versionator.rb

@@ -1,7 +1,7 @@
 # =========================================================================
 #   Ceedling - Test-Centered Build System for C
 #   ThrowTheSwitch.org
-#   Copyright (c) 2010-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   Copyright (c) 2010-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
 #   SPDX-License-Identifier: MIT
 # =========================================================================
 
@@ -71,7 +71,7 @@ class Versionator
           end
         end
       rescue
-        raise CeedlingException.new( "Could not collect version information for vendor component: #{filename}" )
+        raise CeedlingException.new( "Could not collect version information for vendor component ⏩️ #{filename}" )
       end
 
       # Splat version and evaluate it to create Versionator object accessor

data/ceedling.gemspec

@@ -17,34 +17,49 @@ Gem::Specification.new do |s|
   s.authors     = ["Mark VanderVoord", "Michael Karlesky", "Greg Williams"]
   s.email       = ["mark@vandervoord.net", "michael@karlesky.net", "barney.williams@gmail.com"]
   s.homepage    = "https://throwtheswitch.org/ceedling"
-  s.summary     = "Ceedling is a build automation tool for C unit tests and releases. It's a member of the ThrowTheSwitch.org family of tools. It's built upon Unity and CMock."
+  s.summary     = "Ceedling is a build automation tool for C unit tests and releases. It is a member of the ThrowTheSwitch.org family of tools, built upon Unity, CMock, and CException."
   s.description = <<-DESC
-Ceedling is a build automation tool that helps you create and run C unit test suites.
+Ceedling is a build automation tool for C projects. It is especially adept at building and executing unit test suites — even for tricky embedded systems.
 
-Ceedling provides two core functions: 
-  [1] It packages up several tools including the C unit test framework Unity, the mock generation tool CMock, and other features. 
-  [2] It simplifies tool configuration for embedded or native C toolchains and automates the running and reporting of tests.
+Ceedling provides three core functions:
+  [1] It packages up several tools including the C unit test framework Unity, the mock generation tool CMock, and other complementary frameworks and libraries.
+  [2] It simplifies configuration for C toolchains.
+  [3] It automates the running and reporting of test suites as well as release builds.
 
-Ceedling projects are created with a YAML configuration file. A variety of conventions within the tool simplify generating mocks from C files and assembling suites of unit test functions.
+Ceedling projects start with a YAML configuration file. A variety of conventions simplify assembling suites of unit test functions and producing release builds.
   DESC
   s.licenses    = ['MIT']
 
   s.metadata = {
     "homepage_uri"      => s.homepage,
     "bug_tracker_uri"   => "https://github.com/ThrowTheSwitch/Ceedling/issues",
-    "documentation_uri" => "https://github.com/ThrowTheSwitch/Ceedling/blob/master/docs/CeedlingPacket.md",
-    "mailing_list_uri"  => "https://groups.google.com/forum/#!categories/throwtheswitch/ceedling",
-    "source_code_uri"   => "https://github.com/ThrowTheSwitch/Ceedling"
+    "documentation_uri" => "https://throwtheswitch.github.io/Ceedling/",
+    "mailing_list_uri"  => "https://throwtheswitch.discourse.group",
+    "source_code_uri"   => "https://github.com/ThrowTheSwitch/Ceedling",
+    "funding_uri"       => "https://github.com/sponsors/ThrowTheSwitch"
   }
   
   s.required_ruby_version = ">= 3.0.0"
   
-  s.add_dependency "thor", "~> 1.3"
+  # Used for both development and runtime
   s.add_dependency "rake", ">= 12", "< 14"
-  s.add_dependency "deep_merge", "~> 1.2"
+
   s.add_dependency "diy", "~> 1.1"
   s.add_dependency "constructor", "~> 2"
+  s.add_dependency "thor", "~> 1.3"
+  s.add_dependency "deep_merge", "~> 1.2"
+
+  # `erb` is no longer a default gem on some Ruby versions Ceedling supports;
+  # it must be declared explicitly for plain `gem install` (non-Bundler) users.
+  # >= 2.2: minimum `erb` version supporting what Ceedling uses. A loose floor lets
+  # Ruby's own built-in `erb` satisfy this on any Ruby that still bundles one,
+  # avoiding an unnecessary fetch + native-compile of standalone `erb`/`cgi` gems.
+  s.add_dependency "erb", ">= 2.2"
+  # `benchmark` is no longer part of the default gems with Ruby 3.5
+  s.add_dependency "benchmark", ">= 0.3"
+
   s.add_dependency "unicode-display_width", "~> 3.1"
+  s.add_dependency "parallel", "~> 1.26"
 
   # Files needed from submodules
   s.files         = []
@@ -56,9 +71,11 @@ Ceedling projects are created with a YAML configuration file. A variety of conve
   s.files        += Dir['vendor/unity/auto/**/*.rb']
   s.files        += Dir['vendor/unity/src/**/*.[ch]']
 
-  s.files       += Dir['**/*']
-  s.test_files   = Dir['test/**/*', 'spec/**/*', 'features/**/*']
-  s.executables  = ['ceedling'] # bin/ceedling
+  s.files        += Dir['**/*']
+  s.files.reject! { |f| f.start_with?('site-web/') }
+
+  s.test_files = Dir['test/**/*', 'spec/**/*', 'features/**/*']
+  s.executables = ['ceedling'] # bin/ceedling
 
   s.require_paths = ["lib", "vendor/cmock/lib"]
 end

data/config/test_environment.rb

@@ -1,7 +1,7 @@
 # =========================================================================
 #   Ceedling - Test-Centered Build System for C
 #   ThrowTheSwitch.org
-#   Copyright (c) 2010-25 Mike Karlesky, Mark VanderVoord, & Greg Williams
+#   Copyright (c) 2010-26 Mike Karlesky, Mark VanderVoord, & Greg Williams
 #   SPDX-License-Identifier: MIT
 # =========================================================================
 

data/docs/BreakingChanges.md

@@ -1,13 +1,24 @@
 # 🌱 Ceedling Breaking Changes
 
-These breaking changes are complemented by two other documents:
+These breaking changes are complemented by three other documents:
 
-1. 🔊 **[Release Notes](ReleaseNotes.md)** for announcements, education, acknowledgements, and known issues.
+1. 🔊 **[Release Notes](ReleaseNotes.md)** for announcements, education, and acknowledgements.
 1. 🪵 **[Changelog](Changelog.md)** for a structured list of additions, fixes, changes, and removals.
+1. 🐛 **[Known Issues](KnownIssues.md)** for a list of presently known problems and limitations.
 
 ---
 
-# [1.0.0 pre-release] — 2024-11-28
+# [1.1.0] — 2026-07-16
+
+## `--ruby-replacement` CLI flag to enable inline Ruby string expansion
+
+As a security precaution, [inline Ruby string expansion][inline-ruby-string-expansion] within project configuration strings is now disabled by default. The feature still exists and functions, but it must be specifically enabled by the user at the command line each time Ceedling executes.
+
+[inline-ruby-string-expansion]: https://throwtheswitch.github.io/Ceedling/1.1.0/configuration/project-file/#inline-ruby-string-expansion
+
+---
+
+# [1.0.0] — 2025-01-01
 
 ## Explicit `:paths` ↳ `:include` entries in the project file
 
@@ -83,7 +94,9 @@ Automatic quoting has been removed. If you need a quoted executable, simply expl
 ```yaml
 :tools:
   :funky_compiler:
-    :executable: \"Code Cranker\"
+    # YAML explicitly requires the outer quotation marks.
+    # The command line requires the inner escaped quotation marks.
+    :executable: "\"Code Cranker\""
 ```
 
 ## Build output directory structure changes
@@ -181,6 +194,16 @@ In addition, a previously undocumented feature for merging a second configuratio
 
 Thorough documentation on Mixins and the new options for loading a project configuration can be found in _[CeedlingPacket](CeedlingPacket.md))_.
 
+## Replaced `options:` files, environment project specifications, and nested project files with comprehensive `mixins` feature
+
+The following features have all been removed from Ceedling's functionality. No need to worry, though. The new `mixins` feature can handle all the situations these features previously supported, and much more. Check out the [documentation](CeedlingPacket.md) for more detail.
+
+ - `options:blah.yml` command-line options (see `--mixin` command line option)
+ - The corresponding `options_paths:` key in the project.yml file no longer has any effect. (see `:mixins:` ➡️ `:load_paths:` project.yml specification)
+ - The `:import:` section of the `project.yml` has been replaced (see `:mixins:` ➡️ `:enabled:` section)
+ - `CEEDLING_PROJECT_FILE` environment variable (see `CEEDLING_MIXIN_#` specification)
+ - `CEEDLING_SER_FILE` environment variable (see `CEEDLING_MIXIN_#` specification)
+
 ## Tool definition inline Ruby evaluation replacement removed (inline Ruby string expansion remains)
 
 Reaching back to the earliest days of Ceedling, tool definitions supported two slightly different string replacement options that executed at different points in a build’s lifetime. Yeah. It was maybe not great.

data/docs/CONTRIBUTING.md

@@ -54,7 +54,7 @@ In short, since you are most likely a developer, **provide a ticket that you wou
 
 - **Review the documentation** before opening a new issue.
 
-- **Do not open a duplicate issue!** Search through existing issues to see if your issue has previously been reported. If your issue exists, comment with any additional information you have. You may simply note "I have this problem too", which helps prioritize the most common problems and requests. 
+- **Try not to open a duplicate issue** Search through existing issues to see if your issue has previously been reported. If your issue exists, comment with any additional information you have. You may simply note "I have this problem too", which helps prioritize the most common problems and requests. 
 
 - **Prefer using [reactions](https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/)**, not comments, if you simply want to "+1" an existing issue.
 
@@ -80,8 +80,6 @@ You can triage issues which may include reproducing bug reports or asking for ad
 
 We **love** pull requests! Before [forking the repo](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) and [creating a pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests) for non-trivial changes, it is usually best to first open an issue to discuss the changes, or discuss your intended approach for solving the problem in the comments for an existing issue.
 
-For most contributions, after your first pull request is accepted and merged, you will be [invited to the project](https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/inviting-collaborators-to-a-personal-repository) and given **push access**. :tada:
-
 *Note: All contributions will be licensed under the project's license.*
 
 - **Smaller is better.** Submit **one** pull request per bug fix or feature. A pull request should contain isolated changes pertaining to a single bug fix or feature implementation. **Do not** refactor or reformat code that is unrelated to your change. It is better to **submit many small pull requests** rather than a single large one. Enormous pull requests will take enormous amounts of time to review, or may be rejected altogether. 
@@ -157,15 +155,7 @@ See also: #456, #789
 
 ## :white_check_mark: Pull Request Checklist
 
-Not all Pull Requests require these things, but here's a great list of things to check to see if it makes sense for your situation:
-
- - [ ] Are the changes complete?
- - [ ] Are there tests for the new functionality?
- - [ ] Are the changes passing the style checks?
- - [ ] Is there documentation for the new functionality?
- - [ ] Has the change been added to `Changelog.md`?
- - [ ] Has the change been added to `ReleaseNotes.md`?
- - [ ] Have new config options been added as defaults to the `project.yml` files?
+Not all Pull Requests require these things, but [here's a great list](CeedlingPullRequestChecklist.md) of things to check to see if it makes sense for your situation:
 
 ## :heart: Who Loves Emoji?
 

data/docs/CeedlingPullRequestChecklist.md

@@ -0,0 +1,24 @@
+# 🌱 Ceedling Pull-Request Checklist
+
+Hello lovely developers! We hear you're interested in submitting some work to our project. Thanks! We really appreciate it! 
+
+Below is a quick checklist of the things that need to be done before a full PR is merged to our project. Don't worry. You're not responsible for ALL of it. We'll accept your contribution however you are able to make it, with our thanks. But if you have some extra time and would like to maximize your contribution, here's a handy reference!
+
+### Documentation
+
+ - [ ] Has `README.md` been updated? (if it provides a huge feature or change... or maybe version bump)
+ - [ ] Has `CeedlingPacket.md` been updated? (if it provides a new or changed feature)
+ - [ ] Has `ReleaseNotes.md` been updated? (if it provides a new or changed feature)
+ - [ ] Has `Changelog.md` been updated? (if it fixes something or provides something new)
+ - [ ] Has `BreakingChanges.md` been updated? (if it changes compatibility with something that has existed before)
+
+ ### Software
+
+ - [ ] Does it follow our coding standards?
+ - [ ] Are all existing tests passing?
+ - [ ] Are there new tests added and passing?
+ - [ ] Have new config options been added as defaults to the `project.yml` file?
+ - [ ] Should new config options be added to example projects' `project.yml` files?
+ - [ ] Does the feature follow our "Logical Defaults" philosophy where possible?
+ - [ ] Has it passed a peer review?
+ - [ ] Does it pass CI (continuous integration) tests?

data/docs/Changelog.md

@@ -2,20 +2,210 @@
 
 This format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-This changelog is complemented by two other documents:
+This changelog is complemented by three other documents:
 
-1. 🔊 **[Release Notes](ReleaseNotes.md)** for announcements, education, acknowledgements, and known issues.
+1. 🔊 **[Release Notes](ReleaseNotes.md)** for announcements, education, and acknowledgements.
 1. 💔 **[Breaking Changes](BreakingChanges.md)** for a list of impacts to existing Ceedling projects.
+1. 🐛 **[Known Issues](KnownIssues.md)** for a list of presently known problems and limitations.
 
 ---
 
-# [1.0.0 pre-release] — 2024-11-28
+# [1.1.0] — 2026-07-16
+
+## 🌟 Added
+
+### Partials
+
+[A Partial](https://throwtheswitch.github.io/Ceedling/1.1.0/testing-guide/partials/) is a new feature that allows a test author to work with portions of the same C module under test differently from within the same test file.
+
+With Partials, a test can now cause some functions in the source module under test to be mocked while other source functions are executed against assertions (see #936). Partials also allow testing of `static` and `inline` functions with no modification of your source code under test.
+
+💲 The Partials feature made possible thanks to a generous corporate sponsor via a [Ceedling Assist](https://www.thingamabyte.com/ceedling) engagement.
+
+### Two more example projects plus expanded `temp_sensor` project
+
+`wondrous_forest` and `cipher_quest` join the existing `temp_sensor` project. All example projects now have [comprehensive documentation](https://throwtheswitch.github.io/Ceedling/1.1.0/getting-started/example-projects/).
+
+1. The `wondrous_forest` test-only project demonstrates using [Partials](https://throwtheswitch.github.io/Ceedling/1.1.0/testing-guide/partials/) in sample code reasonably representative of real-world use.
+1. The `cipher_quest` project is both a release and test build project that demonstrates conditional compilation builds (`ifdef`) and using [Mixins](https://throwtheswitch.github.io/Ceedling/1.1.0/configuration/mixins) to control builds.
+
+The existing `temp_sensor` project has been expanded to more fully illustrate testing for embbeded development. It now shows a pure C approach to creating hardware access standins that allow testing of peripheral manipulation. The approach demonstrated divorces unit tests from any actual hardware dependence while preserving production C code as is.
+
+### Documentation site
+
+Ceedling is now complemented by a full, searchable [documentation site](https://throwtheswitch.github.io/Ceedling/).
+
+A local verion of this site that is navigable with your web browser from your filesystem is included within Ceedling and exportable through CLI commands.
+
+### Command line interface additions
+
+- `ceedling help` output now provides links for further support and [Github sponsorship](https://github.com/sponsors/ThrowTheSwitch).
+
+#### New application commands
+
+- `ceedling check` validates your configuration and produces logs from processing it without executing a build.
+- `ceedling docs` exports the new HTML-based documentation site to your local filesystem.
+
+#### Mixins inline YAML
+
+The optional `--mixin` flag for all application commands supporting it now additionally [supports inline YAML](https://throwtheswitch.github.io/Ceedling/1.1.0/configuration/mixins/#-mixin-command-line-flags). Example: `--mixin "=defines: {release: ['MY_SYMBOL']}"`
+
+### Cppcheck static analysis plugin
+
+[Alejandro Rosso](https://github.com/deltalejo)’s excellent [Cppcheck plugin](https://throwtheswitch.github.io/Ceedling/1.1.0/plugins/cppcheck/) has been added to the stock plugin collection (with Alejandro’s permission). We’re excited to make it easier for everyone to use this great addition!
+
+### Valgrind memory check plugin
+
+[James Raphael Tiovalen](https://github.com/jamestiotio)’s helpful [Valgrind plugin](https://throwtheswitch.github.io/Ceedling/1.1.0/plugins/valgrind/) has been updated to work with the latest Ceedling and added to the stock plugin collection. Thank you, James for the great contribution!
+
+### GCov plugin code coverage enhancements
+
+#### Support for Modified Condition / Decision Coverage
+Ceedling’s [GCov plugin](https://throwtheswitch.github.io/Ceedling/1.1.0/plugins/gcov/) for coverage reporting now supports the [Modified Condition / Decision Coverage](https://ldra.com/capabilities/mc-dc/) abilities of GCC 14+ and optionally GCovr 8+.
+
+_NOTE:_ The `ReportGenerator` tool does not support extracting MC/DC even if those metrics are available in the coverage data dumps that it processes. The GCov plugin can provide MC/DC metrics through its simplistic console reports and through the rich reports generated by GCovr.
+
+#### Code coverage for all source files, not just those under test
+
+This feature addition resolves a longstanding feature request for coverage reporting (#329 and others).
+
+The Gcov plugin now includes an `:untested_sources` option that controls how source files not exercised by any test are handled in coverage reporting — from full omission (`:ignore`), to a warning-level filepath listing of files not present in the coverage report (`:list`), to full compile-for-0%-coverage (`:compile`). The default is `:list`.
+
+When `:compile` is active, a `gcov:untested_sources` task is available for iterating coverage compilation for untested sources without needing to re-run an entire `gcov:` test suite build each time. Untested sources can require defines, flags, and platform headers & symbols not present in a test suite configuration.
+
+See the [GCov plugin documentation](https://throwtheswitch.github.io/Ceedling/1.1.0/plugins/gcov/setup#coverage-for-untested-sources) for more details on the new `:untested_sources` option.
+
+### Preprocessing for tests
+
+#### System includes
+Preprocessing support now properly distinguishes and handles system includes (`#include <system.h>`) and user includes (`#include "user.h"`).
+
+#### Fallback preprocessing
+When your toolchain’s preprocessor lacks certain features, Ceedling still attempts to extract information and code from C files through fallback text processing. This fallback processing has been improved in a handful of ways, most notably implementing simple conditional compilation (`#ifdef`) processing.
+
+#### Restored support for `TEST_CASE`, `TEST_RANGE`, and `TEST_MATRIX`
+Ceedling 1.0.0 temporarily lost the ability to handle Unity’s parameterized test case features when test preprocessing was enabled. This has been restored.
+
+### Project configuration
+
+#### `:project` ↳ `:name`
+Optional project name that, if present, adds a new first line to build logging output with the project name.
+
+#### `:test_build` ↳ `:preprocess_force_fallback`
+When test preprocessing is enabled, Ceedling discovers whether your toolchain supports certain preprocessing options. If it does not, Ceedling uses simpler fallback options to extract text from C source and header files. This option overrides that discovery and forces the fallback options to be used. This is primarily used for Ceedling’s self-tests, but it could be handy if the automatic feature probe fails with a false positive.
+
+## 💪 Fixed
+
+- #1011 Performance Improvements.
+- #1014 Line Continuations not working in test name.
+- #1024 Fixed bug in options-handling for warnings log report.
+- Now properly reports timing for single-batch builds (i.e. non-parallel builds).
+- Type handling in example `temp_sensor` project compatible with C23 (and previous C standards).
+- #1120 Fixed (by removal) an overly “helpful” holdover from Ceedling’s earliest days causing certain temporary and backup files to be cleaned that were needed by the user’s IDE and text editing tooling.
+- #1162 Fixes to Partials handling for file encoding / multi-byte characters (e.g. ©) in comment blocks.
+- #1160 Proper handling of locales and file encoding.
+- #1135 Fixed test fixture results handling to properly process Unity’s colored output when enabled.
+- #1114 Fixed `:default_tasks` handling.
+- #1144 Fixed flags for release build linking.
+- #1169 Fixed linking with :libraries ↳ :release.
+- #1112 Fixed (via PR #1171) test failures incorrectly returning exit code 0 when the stdout pretty printer plugin is disabled ([Cory Todd](https://github.com/corytodd)).
+- Restored build failure registration and final build failure summary. Replaced test build failures by exception with build failure registration.
+
+### Mixins
+- #1128 Command line mixin precedence.
+- Revisions to [Mixin documentation](https://throwtheswitch.github.io/Ceedling/latest/configuration/mixins) to correct merge order explanations and clarify Mixins generally.
+
+### `#include`s handling and preprocessing
+- Extensive improvements throughout.
+- PR #1126 Fix for race condition in cache handling of `#include` listings in YAML files.
+- #1015 Probing toolchain for presence of preprocessor directives-only ability.
+- #1085 Fix relative `#include` path handling that broke test build convention.
+- #358 Mocks with relative path in `#include` directive.
+- PR #1056 Fix for extracting `#include` directive filenames that contain dashes.
+- #1127 Fixes to path handling in `#include` directives.
+- #1158 Fixes for `#include` filtering in test runner generation.
+
+### GCov plugin
+- `:gcov` section of `:flags` is able to use filename matchers again (like `:test` section).
+- #1115 Fixed Gcov plugin for Gcovr configuration file handling.
+- #1161 Fixed “Found no coverage results” when system headers are processed by coverage.
+- #1170 GCovr summary not passed through to NORMAL logging at end of a GCov plugin build.
+- #1081 Fixes for Gcovr summary cooperating with coverage threshold failures.
+- Prevention of coverage corruption during `ReportGenerator` reporting runs.
+
+## ⚠️ Changed
+
+- Significant refactoring and improvements to logging and parallel processing.
+- Streamlined preprocessing, eliminating redundant steps and reducing memory usage.
+- Resolved ambiguity in updated `ceedling new` handling from 0.31.1 to 1.0.0.
+- Release build logging now matches test build logging.
+- Fixes for typos and grammar in documentation and logging.
+- Added documentation / commented sample in example _project.yml_ for CMock `:treat_inlines` inline function patterns option (PR #1096).
+- 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)).
+
+### Expanded [Backtrace handling](https://throwtheswitch.github.io/Ceedling/1.1.0/configuration/reference/project/#use_backtrace)
+- Provides more and better crash details for `:simple` and `:gdb` options.
+- `:gdb` option captures a full log file from `gdb` output and provides that filepath in the test case crash report.
+
+### Mixins
+- PR #1003 improvements for Mixin merges — clearer logging and edge case handling.
+- Added warning logging if a Mixin contains mixins (nesting is not supported).
+- Mixins now merge list content according to mixin priority. In all cases but one, a higher priority mixin inserts its list content before the content of the existing list to which it is merging. In the case of `:tools` `:arguments` lists, insertion occurs at the end of the arguments list to enable the typical CLI convention of rightmost argument having the highest priority.
+
+### Plugins
+- The GCov plugin now compiles all files with coverage (and filters out unneeded framework results) in order to meet the stricter coverage handling that began with GCC 14. This change is backwards and forwards compatible with virtually all versions of GCC and the GCov plugin’s supporting utilities.
+- Expanded plugin hook events & updated all plugins accordingly:
+   - `pre_test_build` & `post_test_build` hooks.
+   - `pre/post_release` hooks renamed to `pre_release_build` & `post_release_build`.
+   - Build event hooks include stopwatch values in seconds (floating point) as arguments.
+   - Test build steps include a new context argument that exposes event origination (e.g. `test`, `gcov`, etc.).
+- [`command_hooks` plugin](https://throwtheswitch.github.io/Ceedling/1.1.0/plugins/command-hooks/) updated with new hooks and arguments.
+- [`report_tests_log_factory` plugin](https://throwtheswitch.github.io/Ceedling/1.1.0/plugins/report-tests-log-factory/)
+   - All generated reports incorporate `:project` ↳ `:name` from your configuration, if available.
+   - Incorporated new test build time tracking in reports that support it.
+   - Improved the design of the HTML report option.
+      ![](mkdocs/plugins/sample_html_report.png)
+
+### Security
+- Migrated all YAML processing to use safe loading. Safe loading constrains YAML deserialization to data structures such as hashes and lists. Unsafe loading is capable of deserializing arbitrary Ruby objects that could be used maliciously by a bad actor polluting a YAML file loaded by Ceedling.
+- [Inline Ruby string expansion](https://throwtheswitch.github.io/Ceedling/1.1.0/configuration/project-file/#inline-ruby-string-expansion) available in project configuration handling is now disabled by default. It can only be enabled via a Ceedling command line flag `--ruby-replacement`.
+
+## 👋 Removed
+
+- _CeedlingPacket.md_ user manual (superseded by [new documentation site](https://throwtheswitch.github.io/Ceedling/) and local bundle).
+- _PluginDevelopmentGuide.md_ (superseded by [new documentation site](https://throwtheswitch.github.io/Ceedling/) and local bundle).
+
+---
+
+# [1.0.1] — 2025-01-30
+
+## 💪 Fixed
+
+- `#978` -- Ceedling attempts to link source files that are commented out and/or removed by preprocessor directives
+- `#979` -- FFF plugin generates "warning: already initialized constant CMock" on some platforms
+- `#980` -- FFF original plugin should not be part of release build (le sigh)
+- `#981` -- Ceedling could not find header file to mock when using preprocessor
+- `#982` -- Ceedling did not inject required header file into mock when using preprocessor
+- `#985` -- Macros not being properly hidden from CMock’s parser when using preprocessor
+- `#988` -- Parsing of `TEST_SOURCE_FILE` did not support special characters (like `.`) in filenames
+- `#888` & `#977` -- Unicode characters produce crashes in various places
+- `#996` -- Improved handling and documentation of module generator path options
+- `#998` -- FFF plugin missing required stringio
+- `#1005` -- Additional handling of preprocessing extraction improvements
+- Restored `:use_mocks` default to `true` in Ceedling defaults to match documentation and other mocking defaults in template projects.
+- Resolved a preprocessing issue that could cause the content of a file having a similar filename to that of the file `#include`ing it to become mixed with that file.
+- additional documentation improvements
+
+---
+
+# [1.0.0] — 2025-01-01
 
 ## 🌟 Added
 
 ### Parallel execution of build steps
 
-As was explained in the _[Highlights](#-Highlights)_, Ceedling can now run its internal tasks in parallel and take full advantage of your build system’s resources. Even lacking various optimizations (see _[Known Issues](#-Known-Issues)_) builds are now often quite speedy.
+As was explained in the _[Highlights](#-Highlights)_, Ceedling can now run its internal tasks in parallel and take full advantage of your build system’s resources. Even lacking various optimizations (see _[Known Issues](KnownIssues.md)_) builds are now often quite speedy.
 
 Enabling this speedup requires either or both of two simple configuration settings. See Ceedling’s [documentation](CeedlingPacket.md) for `:project` ↳ `:compile_threads` and `:project` ↳ `:test_threads`.
 
@@ -182,7 +372,7 @@ A shortcut for adding arguments to an existing tool defition already existed. Th
     - --flag2
 ```
 
-### Gcov plugin: Support for `gcovr`'s `--merge-mode-functions` for v6.0+
+### Gcov plugin: Support for `gcovr`’s `--merge-mode-functions` for v6.0+
 
 Starting with `gcovr` v6.0 (now at v7.2), report generation can encounters a fatal error if multiple coverage results exist for the same function. This is a very possible scenario with Ceedling 1.0.0 now being able to build and run the same same test executable multiple ways.
 

data/docs/KnownIssues.md

@@ -0,0 +1,26 @@
+# 🌱 Ceedling Known Issues
+
+Known issues are complemented by three other documents:
+
+1. 🔊 **[Release Notes](ReleaseNotes.md)** for announcements, education, and acknowledgements.
+1. 🪵 **[Changelog](Changelog.md)** for a structured list of additions, fixes, changes, and removals.
+1. 💔 **[Breaking Changes](BreakingChanges.md)** for a list of impacts to existing Ceedling projects.
+
+---
+
+## 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. 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. 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.0.0 — 2025-01-01
+
+1. The new internal pipeline 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. 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.