fix(ebuild): validate toolchain extra_cflags/extra_ldflags at config load - #88
Merged
srpatcha merged 2 commits intoSep 1, 2026
Merged
Conversation
toolchain.extra_cflags and toolchain.extra_ldflags were accepted as-is, so a scalar string silently became a list of characters when later treated as a sequence. Reject non-list values and non-string items during config loading, matching the existing validation for target flag fields. Signed-off-by: Furqan Munir <furqan72672@gmail.com>
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The changes are small, consistent with existing target-field validation patterns, and are covered by focused regression tests for the newly enforced constraints.
Pull request overview
This PR tightens configuration validation in load_config() by rejecting invalid toolchain.extra_cflags / toolchain.extra_ldflags values at parse time, preventing scalar strings (and other non-list / non-string cases) from later being misinterpreted as sequences and producing malformed compiler/linker arguments.
Changes:
- Added
_parse_toolchain_flag_list()to validate toolchain flag fields aslist[str]and raiseConfigErroron invalid input. - Updated
_parse_toolchain()to use the new validation forextra_cflagsandextra_ldflags. - Added parametrized regression tests ensuring both fields reject non-lists and lists containing non-strings.
Verification
- Reviewer: NOT RUN (no tests or linters executed in this review).
- Author-reported (from PR description):
tests/ebuild/test_config_validation.pyandtests/ebuild/test_smoke_imports.pywere run; the remaining failure is described as pre-existing and out of scope.
File summaries
| File | Description |
|---|---|
| ebuild/core/config.py | Adds parse-time validation for toolchain extra flag lists and wires it into toolchain parsing. |
| tests/ebuild/test_config_validation.py | Adds regression coverage for invalid toolchain extra flag field types/contents. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
srpatcha
previously approved these changes
Sep 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
load_config()now validatestoolchain.extra_cflagsandtoolchain.extra_ldflagsinbuild.yaml, rejecting non-list values and lists containing non-string items at config load time instead of letting them leak into toolchain resolution / build generation.Type of Change
Issue being addressed
toolchain.extra_cflags/extra_ldflagswere accepted verbatim. A scalar string (e.g.extra_cflags: -mcpu=cortex-m4) would silently become a list of characters when the value is later treated as a sequence, producing malformed compiler arguments.Approach
Validate the two fields the same way target flag fields (
cflags,ldflags,sources, etc.) are already validated: require a list, and require every item to be a string, otherwise raiseConfigError. Failing fast at parse time is consistent with the existing parser behaviour.Changes
_parse_toolchain_flag_list()inebuild/core/config.py, mirroring the existing target-field validation style._parse_toolchain()now validates both flag fields before constructingToolchainConfig.tests/ebuild/test_config_validation.pycovering scalar and non-string cases for both fields.Testing
py -m pytest tests/ebuild/test_config_validation.py -q→ 18 passedpy -m flake8 ebuild/core/config.py tests/ebuild/test_config_validation.py→ no new violations (3 pre-existing E501s remain, unrelated)py -m pytest tests/ebuild/test_smoke_imports.py -q→ 45 passed, 1 failed (pre-existingSyntaxErrorinebuild/build/dispatch.py, see below)Pre-Submission Checklist
type(scope): descriptionconventiondispatch.pyissueAdditional Notes / Limitations
build.yamlfiles that used a scalar string for these fields will now fail fast. Intentional, and consistent with the target flag fields.ebuild/build/dispatch.py(duplicate unreachableelse:causing aSyntaxErrorat line 133). It is out of scope here and recorded inTASKS.mdas T-002. It also surfaces a conflict betweentests/ebuild/test_dispatch.py(expectsValueError) andtests/unit/test_dispatch.py(expectsRuntimeError), which needs a design decision before it can be fixed.