ceedling 1.1.0 → 1.1.2

data/docs/mkdocs/plugins/command-hooks.md

@@ -4,7 +4,7 @@ Easily run command line tools and scripts at various points in a Ceedling build.
 
 ## Plugin Overview
 
-This plugin allows you to skip creating a full Ceedling plugin for many common use cases. It links Ceedling's programmatic `Plugin` code hooks to easily managed tool definitions. 
+This plugin allows you to skip creating a full Ceedling plugin for many common use cases. It links Ceedling’s programmatic `Plugin` code hooks to easily managed tool definitions. 
 
 ## Setup
 
@@ -40,7 +40,9 @@ See the commented examples below.
 
 Each Ceedling tool requires an `:executable` string and an optional `:arguments` list. See the [`:tools` configuration reference][tools-doc] to understand how to craft your argument list and other tool options.
 
-This plugin passes one or two runtime parameters for use in a hook's tool argument list depending on the hook. These parameters are referenced with Ceedling tool argument expansion identifiers `${1}`, `${2}`, etc. Wherever you place `${1}` or `${2}` in your tool argument list, they expand in the command line Ceedling constructs with the parameters this plugin provides for that build step hook. The list of build step hooks below documents which parameters are available for each hook.
+This plugin passes one or two runtime parameters for use in a hook’s tool argument list depending on the hook. These parameters are referenced with Ceedling tool argument expansion identifiers `${1}`, `${2}`, etc. Wherever you place `${1}` or `${2}` in your tool argument list, they expand in the command line Ceedling constructs with the parameters this plugin provides for that build step hook. The list of build step hooks below documents which parameters are available for each hook.
+
+Each tool may optionally include a `:name` — a simple nickname used in log and error messages. If omitted, the plugin forms a default name from the hook’s key (e.g. `pre_mock_generate`). For a hook configured with a list of tools, the default name additionally includes the tool’s position in the list (e.g. `post_link_execute_0`, `post_link_execute_1`). See the commented examples below.
 
 [tools-doc]: ../configuration/reference/tools.md
 
@@ -65,6 +67,7 @@ When logging is enabled and logging conditions are appropriate, any output from
   :pre_mock_generate:
     # This tool is organized as a sub-hash beneath the command hook key
     :executable: python
+    :name: 'mock prep script' # Explicit nickname used in log/error messages
     :arguments:
       - my_script.py
       - --some-arg
@@ -74,18 +77,20 @@ When logging is enabled and logging conditions are appropriate, any output from
   # Hook called for each linking operation
   # Here, we are performing two tasks for the same build step hook, converting a
   # binary executable to S-record format and, then, archiving with other artifacts.
+  # Neither tool below is given a :name -- the plugin defaults them to
+  # "post_link_execute_0" and "post_link_execute_1"
   :post_link_execute:
     # These tools are organized in a YAML list beneath the command hook key
     - :executable: objcopy.exe
       :arguments:
-        - ${1} # Replaced with the filepath to the linker's binary artifact output
+        - ${1} # Replaced with the filepath to the linker’s binary artifact output
         - output.srec
         - --strip-all
     - :executable: 
       :arguments: tar.exe
         - -acf
         - awesome_build.zip
-        - ${1} # Replaced with the filepath to the linker's binary artifact output
+        - ${1} # Replaced with the filepath to the linker’s binary artifact output
         - memory_report.txt
 ```
 
@@ -102,7 +107,7 @@ As an example, consider a Ceedling project with ten test files and seventeen moc
 * 10 occurrences of the `:pre_test` and `:post_test` hooks.
 * 17 occurrences of the `:pre_mock_generate` and `:post_mock_generate` hooks.
 * 10 occurrences of the `:pre_test_runner_generate` and `:post_test_runner_generate` hooks.
-* 27(+) occurrences of the `:pre_compile` and `:post_compile` hooks. These hooks would be called 27 times for test file and mock file compilation. A test suite build will also include compilation of the source files under tests, Unity's source, CMock's source, and generated test runner C files -- easily more than another two dozen compilation hook calls.
+* 27(+) occurrences of the `:pre_compile` and `:post_compile` hooks. These hooks would be called 27 times for test file and mock file compilation. A test suite build will also include compilation of the source files under tests, Unity’s source, CMock’s source, and generated test runner C files -- easily more than another two dozen compilation hook calls.
 * 10 occurrences of the `:pre_link` and `:post_link` hooks for test executable creation.
 * 10 occurrences of the `:pre_test_fixture_execute` and `:post_test_fixture_execute` hooks for running test executables and gathering the results of the tests cases they contain.
 * 1 occurrence of the `:post_test_build` hook.
@@ -130,17 +135,17 @@ The parameter available to a tool (`${1}`) when the hook is called is a floating
 
 Called just before each test begins its build pipeline and just after all context for that build has been gathered.
 
-The parameter available to a tool (`${1}`) when the hook is called is the test's filepath.
+The parameter available to a tool (`${1}`) when the hook is called is the test’s filepath.
 
 ### `:post_test`
 
 Called just after each test completes its build and execution.
 
-The parameter available to a tool (`${1}`) when the hook is called is the test's filepath.
+The parameter available to a tool (`${1}`) when the hook is called is the test’s filepath.
 
 ### `:pre_test_build`
 
-Called once just before the full test build pipeline begins (before any individual test's configure, preprocess, compile, link, or execute steps).
+Called once just before the full test build pipeline begins (before any individual test’s configure, preprocess, compile, link, or execute steps).
 
 Two parameters are available to a tool when the hook is called:
 
@@ -200,7 +205,7 @@ The parameter available to a tool (`${1}`) when the hook is called is the filepa
 
 If preprocessing is in use, this is called just before each test file is preprocessed before runner generation.
 
-The parameter available to a tool (`${1}`) when the hook is called is the test's filepath.
+The parameter available to a tool (`${1}`) when the hook is called is the test’s filepath.
 
 See [_Conventions & Behaviors_][preprocessing] for details on how Ceedling preprocessing operates.
 
@@ -208,7 +213,7 @@ See [_Conventions & Behaviors_][preprocessing] for details on how Ceedling prepr
 
 If preprocessing is in use, this is called just after each test file is preprocessed.
 
-The parameter available to a tool (`${1}`) when the hook is called is the test's filepath.
+The parameter available to a tool (`${1}`) when the hook is called is the test’s filepath.
 
 See [_Conventions & Behaviors_][preprocessing] for details on how Ceedling preprocessing operates.
 
@@ -216,13 +221,13 @@ See [_Conventions & Behaviors_][preprocessing] for details on how Ceedling prepr
 
 Called just before each test file is processed by test runner generation.
 
-The parameter available to a tool (`${1}`) when the hook is called is the test's filepath.
+The parameter available to a tool (`${1}`) when the hook is called is the test’s filepath.
 
 ### `:post_runner_generate`
 
 Called just after each test runner is generated.
 
-The parameter available to a tool (`${1}`) when the hook is called is the test's filepath.
+The parameter available to a tool (`${1}`) when the hook is called is the test’s filepath.
 
 ### `:pre_compile_execute`
 
@@ -240,13 +245,13 @@ The parameter available to a tool (`${1}`) when the hook is called is the filepa
 
 Called just before any binary artifact—test or release—is linked.
 
-The parameter available to a tool (`${1}`) when the hook is called is the binary output artifact's filepath.
+The parameter available to a tool (`${1}`) when the hook is called is the binary output artifact’s filepath.
 
 ### `:post_link_execute`
 
 Called just after a binary artifact is linked.
 
-The parameter available to a tool (`${1}`) when the hook is called is the binary output artifact's filepath.
+The parameter available to a tool (`${1}`) when the hook is called is the binary output artifact’s filepath.
 
 ### `:pre_test_fixture_execute`
 
@@ -256,7 +261,7 @@ The parameter available to a tool (`${1}`) when the hook is called is the filepa
 
 ### `:post_test_fixture_execute`
 
-Called just after each test's fixture is executed and test results are collected.
+Called just after each test’s fixture is executed and test results are collected.
 
 The parameter available to a tool (`${1}`) when the hook is called is the filepath of the binary artifact that was executed by the fixture.
 

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

@@ -1,126 +1,61 @@
 # GCovr Configuration
 
-All reports generated by `gcovr` are found in `<build root>/artifacts/gcov/gcovr/`.
+!!! note
+    All reports generated by `gcovr` are found in `<build root>/artifacts/gcov/gcovr/`.
 
-## HTML reports
-
-Generation of HTML reports may be modified with the following configuration items.
-
-```yaml
-:gcov:
-  :gcovr:
-    # HTML report filename.
-    :html_artifact_filename: <filename>
-
-    # Use 'title' as title for the HTML report.
-    # Default is 'Head'. (gcovr --html-title)
-    :html_title: <title>
-
-    # If the coverage is below MEDIUM, the value is marked as low coverage in the HTML report.
-    # MEDIUM has to be lower than or equal to value of html_high_threshold.
-    # If MEDIUM is equal to value of html_high_threshold the report has only high and low coverage.
-    # Default is 75.0. (gcovr --html-medium-threshold)
-    :html_medium_threshold: 75
-
-    # If the coverage is below HIGH, the value is marked as medium coverage in the HTML report.
-    # HIGH has to be greater than or equal to value of html_medium_threshold.
-    # If HIGH is equal to value of html_medium_threshold the report has only high and low coverage.
-    # Default is 90.0. (gcovr -html-high-threshold)
-    :html_high_threshold: 90
-
-    # Set to 'true' to use absolute paths to link the 'detailed' reports.
-    # Defaults to relative links. (gcovr --html-absolute-paths)
-    :html_absolute_paths: <true|false>
-
-    # Override the declared HTML report encoding. Defaults to UTF-8. (gcovr --html-encoding)
-    :html_encoding: <html_encoding>
-```
-
-## Cobertura XML reports
+The following sections first discuss GCovr options in common across reports
+and then break out report-specific options.
 
-Generation of Cobertura XML reports may be modified with the following configuration items.
+## GCovr options
 
-```yaml
-:gcov:
-  :gcovr:
-    # Set to 'true' to pretty-print the Cobertura XML report, otherwise set to 'false'.
-    # Defaults to disabled. (gcovr --xml-pretty)
-    :cobertura_pretty: <true|false>
+### Project config vs. GCovr config file
 
-    # Override default Cobertura XML report filename.
-    :cobertura_artifact_filename: <filename>
-```
+GCovr can be configured in two ways:
 
-## SonarQube XML reports
+1. Using one or more of the options documented below in the `:gcov` section
+   of your project configuration.
+1. Through a Gcovr configuration file (.ini format) provided to Gcovr via
+   the speciial `:config_file` value in the `:gcov` section of your project
+   configuration.
 
-Generation of SonarQube XML reports may be modified with the following configuration items.
+### Gcovr configuration file
 
-```yaml
-:gcov:
-  :gcovr:
-    # Override default SonarQube XML report filename.
-    :sonarqube_artifact_filename: <filename>
-```
+!!! warning "Using a gcovr configuration file"
+    When `:config_file` is set, Ceedling passes only `--root` (`:report_root`) 
+    and `--config` (`:config_file`) to `gcovr` at the command line from your
+    plugin configuration. This prevents overriding config file settings with 
+    CLI arguments. You must provide any settings that would have been provided 
+    by the Gcov plugin.
 
-## JSON reports
+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).
 
-Generation of JSON reports may be modified with the following configuration items.
+```ini
+[gcovr]
+; You will need to revise these example exclude patterns to match your
+; project directories and file naming as they cannot be automatically 
+; provided to Gcovr when a Gcovr configuration file is in use.
 
-```yaml
-:gcov:
-  :gcovr:
-    # Set to 'true' to pretty-print the JSON report, otherwise set 'false'.
-    # Defaults to disabled. (gcovr --json-pretty)
-    :json_pretty: <true|false>
+; Test path(s) exclusions for 'test_' files with .c extensions. 
+exclude = .*test.*/test_.+\.c$
 
-    # Override default JSON report filename.
-    :json_artifact_filename: <filename>
+; Build path exlcude for all generated C files (runners, mocks, partials).
+exclude = .*build/.+\.c$
 ```
 
-## Text reports
-
-Generation of text reports may be modified with the following configuration items.
-Text reports may be printed to the console or output to a file.
+### Plugin project configuration
 
-```yaml
-:gcov:
-  :gcovr:
-    # Override default text report filename.
-    :text_artifact_filename: <filename>
-```
+The following is an exhaustive commented version of all GCovr configuration 
+options exposed through your project configuration file. Only specify those 
+you need or those whose defaults you need to override. You do not need to 
+include all these options in your Gcov plugin configuration.
 
-## Common GCovr options
-
-A number of options exist to control which files are considered part of a 
-coverage report. This Ceedling gcov plugin itself handles the most important 
-aspect — only source files under test are compiled with coverage. Tests, mocks,
-and test runners, are not compiled with coverage.
-
-!!! note "`gcovr` accepts only one report root path"
-    `gcovr` will only accept a single path for `:report_root`. In typical usage,
-    this is of no concern as it is handled automatically. In unusual project
-    layouts, you may need to specify a folder that encompasses _all_ build folders
-    containing coverage result files and optionally, selectively exclude patterns
-    of paths or files. For instance, if your Ceedling project file is not at the
-    root of your project, you may need set `:report_root` as well as
-    `:report_exclude` and `:exclude_directories`.
-
-!!! note "Using a gcovr configuration file"
-    When `:config_file:` is set, Ceedling passes only `--root` and `--config`
-    to gcovr and defers all other settings to that file. This prevents Ceedling
-    from overriding config file values with its CLI arguments. Only `:report_root:`
-    is still applied because Ceedling may invoke gcovr from a different working
-    directory than your project root.
-
-    To preserve the plugin's default filtering of test and build files, include
-    equivalent exclusion patterns in your gcovr config file (adjust for your
-    project's `:test_file_prefix`, test paths, and `:build_root` settings):
-
-    ```ini
-    [gcovr]
-    exclude = .*test.*/test_.+\.c$
-    exclude = .*build/.+\.c$
-    ```
+!!! warning "`gcovr` accepts only one reporting root path"
+    `gcovr` accepts only a single path for `:report_root`. In unusual project
+    layouts, you may need to specify as root a parent folder that includes 
+    _all_ source files and selectively exclude paths or files from coverage 
+    reporting (see `:report_exclude` and `:exclude_directories`).
 
 ```yaml
 :gcov:
@@ -139,8 +74,8 @@ and test runners, are not compiled with coverage.
     # :report_root is still applied because Ceedling may invoke gcovr from a
     # different working directory than your project root.
     #
-    # To preserve the plugin's base filtering behavior, include the following
-    # patterns in your config file (adjust paths to match your project's
+    # To preserve the plugin’s base filtering behavior, include the following
+    # patterns in your config file (adjust paths to match your project’s
     # :test_file_prefix, test paths, and :build_root settings):
     #
     #   [gcovr]
@@ -210,7 +145,7 @@ and test runners, are not compiled with coverage.
 
     # Use a particular gcov executable. (gcovr --gcov-executable).
     # (This may be appropriate and necessary in special circumstances.
-    #  Please review Ceedling's options for modifying tools first.)
+    #  Please review Ceedling’s options for modifying tools first.)
     :gcov_executable: <cmd>
 
     # Exclude branch coverage from lines without useful
@@ -247,5 +182,91 @@ and test runners, are not compiled with coverage.
     # Set the number of threads to use in parallel. (gcovr -j).
     :threads: <count>
 ```
+## HTML reports
+
+Generation of HTML reports may be modified with the following configuration items.
+
+```yaml
+:gcov:
+  :gcovr:
+    # HTML report filename.
+    :html_artifact_filename: <filename>
+
+    # Use 'title' as title for the HTML report.
+    # Default is 'Head'. (gcovr --html-title)
+    :html_title: <title>
+
+    # If the coverage is below MEDIUM, the value is marked as low coverage in the HTML report.
+    # MEDIUM has to be lower than or equal to value of html_high_threshold.
+    # If MEDIUM is equal to value of html_high_threshold the report has only high and low coverage.
+    # Default is 75.0. (gcovr --html-medium-threshold)
+    :html_medium_threshold: 75
+
+    # If the coverage is below HIGH, the value is marked as medium coverage in the HTML report.
+    # HIGH has to be greater than or equal to value of html_medium_threshold.
+    # If HIGH is equal to value of html_medium_threshold the report has only high and low coverage.
+    # Default is 90.0. (gcovr -html-high-threshold)
+    :html_high_threshold: 90
+
+    # Set to 'true' to use absolute paths to link the 'detailed' reports.
+    # Defaults to relative links. (gcovr --html-absolute-paths)
+    :html_absolute_paths: <true|false>
+
+    # Override the declared HTML report encoding. Defaults to UTF-8. (gcovr --html-encoding)
+    :html_encoding: <html_encoding>
+```
+
+## Cobertura XML reports
+
+Generation of Cobertura XML reports may be modified with the following configuration items.
+
+```yaml
+:gcov:
+  :gcovr:
+    # Set to 'true' to pretty-print the Cobertura XML report, otherwise set to 'false'.
+    # Defaults to disabled. (gcovr --xml-pretty)
+    :cobertura_pretty: <true|false>
+
+    # Override default Cobertura XML report filename.
+    :cobertura_artifact_filename: <filename>
+```
+
+## SonarQube XML reports
+
+Generation of SonarQube XML reports may be modified with the following configuration items.
+
+```yaml
+:gcov:
+  :gcovr:
+    # Override default SonarQube XML report filename.
+    :sonarqube_artifact_filename: <filename>
+```
+
+## JSON reports
+
+Generation of JSON reports may be modified with the following configuration items.
+
+```yaml
+:gcov:
+  :gcovr:
+    # Set to 'true' to pretty-print the JSON report, otherwise set 'false'.
+    # Defaults to disabled. (gcovr --json-pretty)
+    :json_pretty: <true|false>
+
+    # Override default JSON report filename.
+    :json_artifact_filename: <filename>
+```
+
+## Text reports
+
+Generation of text reports may be modified with the following configuration items.
+Text reports may be printed to the console or output to a file.
+
+```yaml
+:gcov:
+  :gcovr:
+    # Override default text report filename.
+    :text_artifact_filename: <filename>
+```
 
 <br/><br/>

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

@@ -4,6 +4,12 @@ The `gcov` plugin integrates the code coverage abilities of the GNU compiler
 collection with test builds. It provides simple coverage metrics by default and
 can optionally produce sophisticated coverage reports.
 
+!!! note
+    The Gcov plugin creates a duplicate test build with `gcov:` command line
+    plugin tasks. [This is intentional and needed](../index.md#understanding-plugin-build-duplication).
+
+---
+
 <div class="grid cards" markdown>
 
 -   :material-information-outline: **[Overview][overview]**

data/docs/mkdocs/plugins/index.md

@@ -16,6 +16,46 @@ includes full documentation of its capabilities and configuration options.
 See the [`:plugins` configuration reference](../configuration/reference/plugins.md) 
 for how to enable built-in plugins and load custom plugins in your project.
 
+---
+
+## Understanding plugin build duplication
+
+!!! warning
+    Build-related plugins intentionally execute duplicated builds.
+
+Plugins including [Gcov](gcov/index.md), [Bullseye](bullseye.md), and [Valgrind](valgrind.md)
+recreate test build tasks. That is, the command line build task `test:foo` also exists 
+as `gcov:foo`, `bullseye:foo`, and/or `valgrind:foo` if these plugins are enabled.
+Each of these triggers a full rebuild of the named test with instrumentation 
+activated. **This duplication is intentional and very necessary.**
+
+These plugins modify executable code or the environment in which a test suite 
+executable runs. Duplicating and segregating the build tasks addresses several 
+important issues:
+
+1. **Conflicting interactions**. Enabling multiple plugins without 
+   duplicated tasks (i.e. integrated build tasks) can bring about conflicts and
+   undefined behavior. For instance, Gcov’s instrumentation does not
+   necessarily play nice with Valgrind’s memory-instrumented emulation
+   runtime, and the two should be kept entirely segregated.
+2. **Unforeseen effects**. These plugins can directly alter the functioning of
+   the code under test. For instance, coverage instrumentation inserted into
+   your compiled code can alter its function or timing. As such, it is vital
+   to maintain distinct builds to compare them. Your vanilla test suite build
+   may function slightly differently than the coverage-instrumented build.
+3. **Optional instrumentation**. The `<plugin>:` command line task convention
+   also provides a very simple opt-in scheme. Plugins automatically enabled 
+   for every build drives the desire to optional disable them. Valgrind testing
+   can require 25-50x the execution time of a test suite, and you likely will
+   want the option to easily disable it. While Ceedling could certainly provide
+   that option at the command line for otherwise always-on plugins, this
+   plugin task namespacing scheme naturally accomplished this along with the
+   needs of (1) and (2).
+
+---
+
+## Directory
+
 ### Console Test Results
 
 <div class="grid cards" markdown>

data/docs/mkdocs/plugins/valgrind.md

@@ -4,6 +4,12 @@ Adds Ceedling tasks to run test executables under [Valgrind] memory error
 detection to help find memory leaks, invalid memory accesses, and
 use-after-free bugs in your C code.
 
+!!! note
+    The Valgrind plugin creates a duplicate test build with `valgrind:` 
+    command line plugin tasks. [This is intentional and needed](index.md#understanding-plugin-build-duplication).
+
+---
+
 ## Plugin overview
 
 !!! note "Linux only"

data/docs/mkdocs/testing-guide/partials/index.md

@@ -4,23 +4,25 @@ A _Partial_ is your C code sliced and diced to expose elements for testing
 that you could not otherwise access without rewriting your source code. 
 Think of Partials as a unit testing scalpel.
 
-Partials are useful when a module under test contains:
+Partials are useful when you need to test:
 
-* **`static` or `inline` functions** — These become accessible within 
-  your test code.
+* **`static` or `inline` functions** — These become accessible to 
+  your test code without modifying your source.
 * **File-scoped `static` variables** — The `static` keyword is stripped, 
-  and the variable is automatically made `extern` for easy access within 
-  your test code.
+  and the variable is automatically made `extern` for your test code 
+  with no changes to the source under test.
 * **Function-scoped `static` variables** — These are promoted from
   function scope to module scope so they can be accessed in your
-  test code. Apart from necessary renaming, this works identically to
-  file-scoped `static` variables.
-
-!!! warning "Limitations of Partials"
-    Partials are new to Ceedling with 1.1.0. Carving up C code is tricky
-    business. Complex code _may_ break Ceedling’s lexing or its assumptions 
-    on symbol ordering. Some issues may be [bugs to be reported](../../help.md) 
-    while others may be complexities that Partials are simply unable to resolve.
+  test code just like file-scoped `static` variables.
+* **Same-module mocked functions** — You can mix and match tested and 
+  mocked functions from the same source module. Partials allow mocking 
+  functions inside a module that are called by other functions inside 
+  the same module.
+  
+!!! tip
+    See the [`wondrous_forest`](../../getting-started/example-projects/wondrous-forest.md) 
+    example available within Ceedling for a working example project 
+    demonstrating Partials in action.
 
 ---
 
@@ -69,6 +71,13 @@ Partials are useful when a module under test contains:
 
 </div>
 
+!!! warning "Limitations of Partials"
+    Partials are new to Ceedling with 1.1.0. Carving up C code is tricky
+    business. Complex code _may_ break Ceedling’s lexing or certain assumptions.
+    Some issues may be [bugs to be reported](../../help.md) while others may 
+    be complexities that Partials are simply unable to resolve.
+
+
 [overview]:        overview.md
 [conventions]:     conventions.md
 [directives]:      directives.md

data/lib/ceedling/c_extractor/c_extractor_declarations.rb

@@ -167,7 +167,9 @@ class CExtractorDeclarations
           # Verify this looks like a valid declaration
           # Must have at least a type and identifier
           # Can end with: word character, ], ), }, or " (for string initializers)
-          if declaration =~ /\w+.*[\w\]\)\}"']\s*;$/
+          # `/m` flag: declaration may span multiple lines (e.g. a multiline brace
+          # initializer), so '.' must match embedded newlines too
+          if declaration =~ /\w+.*[\w\]\)\}"']\s*;$/m
             return [true, expand_and_parse(declaration)]
           else
             scanner.pos = start_pos

data/lib/ceedling/c_extractor/c_extractor_preprocessing.rb

@@ -142,8 +142,9 @@ class CExtractorPreprocessing
     return [false, nil] unless success
     text << args
 
-    # Consume optional whitespace before ';'
-    text << (scanner.scan(/[ \t]*/) || '')
+    # Consume optional whitespace before ';' (including newlines, for statements formatted
+    # with the terminating ';' on its own line)
+    text << (scanner.scan(/\s*/) || '')
 
     # Consume the required terminating ';'
     return [false, nil] unless scanner.scan(/;/)
@@ -231,20 +232,32 @@ class CExtractorPreprocessing
 
   # Collect and return the full text of a preprocessing directive starting at '#'.
   # Returns nil if not positioned at '#'. Handles backslash-newline continuations.
+  # String/char literals are consumed verbatim via skip_c_string() so an in-string
+  # escape (e.g. "\n", "\"", "\\") is never mistaken for a line continuation.
   # Trailing whitespace and newlines are stripped from the returned text.
   def _collect_directive(scanner)
     return nil unless scanner.check(/#/)
 
     text = scanner.scan(/#/)
 
-    loop do
-      text += scanner.scan(/[^\n\\]*/) || ''
+    until scanner.eos?
+      text << (scanner.scan(/[^"'\\\n]*/) || '')
+
+      if (ch = scanner.peek(1)) == '"' || ch == "'"
+        before = scanner.pos
+        @c_extractor_code_text.skip_c_string(scanner, ch)
+        text << scanner.string[before...scanner.pos]
+
+      elsif scanner.scan(/\\\n/)
+        text << "\\\n"
 
-      if scanner.scan(/\\\n/)
-        text += "\\\n"
       elsif scanner.scan(/\n/)
-        text += "\n"
+        text << "\n"
         break
+
+      elsif scanner.scan(/\\/)
+        text << '\\'
+
       else
         break  # EOS — no trailing newline
       end

data/lib/ceedling/config/configurator.rb

@@ -11,6 +11,7 @@ require 'ceedling/file_path_utils'
 require 'ceedling/exceptions'
 require 'ceedling/rake_app/rakefile_component_resolver'
 require 'ceedling/config/config_matchinator'
+require 'ceedling/tool_executor'
 require 'deep_merge'
 
 class Configurator
@@ -431,7 +432,7 @@ class Configurator
       end
 
       # Populate name if not given
-      tool[:name] = name.to_s if (tool[:name].nil?)
+      ToolExecutor.default_name!( tool, name.to_s )
 
       # Populate $stderr redirect option
       tool[:stderr_redirect] = StdErrRedirect::NONE if (tool[:stderr_redirect].nil?)