dts: cosmetic improvements to output file layout #90804
Merged
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.
After the introduction of source references in comments by #89410, this PR improves the layout of the generated
zephyr.dts
with the following adjustments:Wrap long item arrays so that they don't create excessively long lines, messing comment formatting.
There is now a lax limit of 80 chars for the array entries, so that the whole block can be read on most screens with a minimum of scrolling, and comments are readily visible after it.
Example (click to open)
Current: extra long lines and unreachable comment blocks
With PR: lines are shortened to a manageable width
Keep properties in input DTS order in each node.
Currently, when a property is updated, its location is not changed and still reflects the order in the initial definition. Grouping the changes makes it easier to see at a glance the block of lines each input file touches.
Example (click to open)
Current: properties in the output file appear to come from multiple scattered changes:
With this PR, properties are sorted by input file:
Review notes:
No functional change to the DTS is introduced.
The
noqa: F821
linter suppression prevents flaggingarray_start
andarray_newline
as undefined variables.This is because these variables are initialized when an opening brace is output (the
else: #MarkerType.UINT*
clause), which is necessarily before any element in a byte or prop array. A sequence of markers not following this pattern would indicate a bug in the DTS parsing code.I also experimented with sorting nodes in the same way, but decided against it. I felt the order of nodes is usually cleaner in CPU/SoC DTS than in the board/application files, so keeping the initial definition order results in a cleaner overall structure of the output DTS.