Skip to content

Soften same-named file disambiguation to resolve-by-search-path-order with a NOTICE - #1212

Merged
mkarlesky merged 2 commits into
next_versionfrom
feature/soften-file-disambiguation-next-version
Aug 16, 2026
Merged

Soften same-named file disambiguation to resolve-by-search-path-order with a NOTICE#1212
mkarlesky merged 2 commits into
next_versionfrom
feature/soften-file-disambiguation-next-version

Conversation

@mkarlesky

Copy link
Copy Markdown
Member

Summary

  • Ambiguous same-named file references (#include, TEST_SOURCE_FILE(), mock resolution, release builds) no longer hard-fail the build. They resolve to the first candidate by search-path order — the same order the compiler's own search paths would consult — logging an informational notice naming what else matched. A wrong guess still surfaces as an ordinary downstream compilation error.
  • Header #include resolution now uses a per-test ordered header list that correctly ranks TEST_INCLUDE_PATH() directories ahead of :paths:include, rather than the previous project-wide, incorrectly-ordered collection.
  • The one deliberate exception: ceedling test:<name> at the command line still hard-fails on an ambiguous name, since there's no downstream compilation step to catch a wrong guess there.
  • TEST_SOURCE_FILE() is now authoritative over the implicit #include-driven header/source correspondence convention: when a directive's own resolved source shares a basename with what the implicit convention would separately resolve, the directive wins outright and the implicit convention's resolution is skipped — avoiding a duplicate-symbol link error from both landing in the source list.

Test plan

  • Full unit suite green (2520 examples, 0 failures)
  • Targeted system specs for every affected area (header/mock/source/release ambiguity, TEST_INCLUDE_PATH() vs :include ranking, TEST_SOURCE_FILE() override, CLI test: task regression guard) green in Docker
  • Full system suite run for final validation (379 examples; only 2 pre-existing, unrelated failures — a docs/ceedling vendoring gap reproduced independently of this change)
  • Documentation updated (conventions.md, Changelog.md)

…er with a NOTICE

Previously, any query (a bare #include, a TEST_SOURCE_FILE() argument, a mock
reference, etc.) that matched more than one same-named project file hard-failed
the build, naming every candidate and refusing to guess. Since Ceedling's own
:paths configuration already produces file collections ordered identically to
the search paths a compiler would use, an ambiguous query now resolves to the
first candidate in that order instead, logging an informational notice naming
what else matched. A wrong guess still surfaces as an ordinary downstream
compilation error rather than an upfront Ceedling failure.

This applies uniformly across header #include resolution (plain and mocked,
with a new per-test ordered header list that correctly ranks TEST_INCLUDE_PATH()
directories ahead of :paths -> :include), source file resolution, and release
builds. The one deliberate exception is `ceedling test:<name>` at the command
line, which still hard-fails on an ambiguous name since there is no downstream
compilation step to catch a wrong guess there.
A test file that both #includes a header and separately names a same-basename
source via TEST_SOURCE_FILE() previously had both resolutions land independently
in the compiled source list, risking a duplicate-symbol link error if they
defined the same functions. TEST_SOURCE_FILE() is now authoritative: when its
own resolved source shares a basename with what the implicit #include-driven
convention would separately resolve, the directive's own file wins outright and
the implicit convention's resolution for that basename is skipped entirely.
This holds unconditionally, even when the implicit resolution would already
have been unambiguous on its own. Header validation itself is unaffected --
only which source file compiles for a shared basename is decided differently.
@mkarlesky
mkarlesky merged commit f21c024 into next_version Aug 16, 2026
23 of 40 checks passed
@mkarlesky
mkarlesky deleted the feature/soften-file-disambiguation-next-version branch August 16, 2026 00:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant