[Jiu-xiao]

The generator uses xr-syntax 0.3.0 for its C++ layout, for assembling generated files and for reading and writing cmake/LibXR.CMake. cpp_layout.py and cmake_text.py are gone, along with every regular expression that parsed CMake.

Changes

• STM32, HPM and MSPM0 code generation lay out statements with xr_syntax.format.layout_statement.
• app_main.cpp, app_main.h and flash_map.hpp are assembled by CppFileBuilder.
• LibXR.CMake is read and written through the CMake frontend.

Generated output

• Generated files are byte-identical to libxr 6.0.1 on bsp-dev-c (default and sentry configs), bsp-dev-mc02 and bsp_stm32f103. The one exception is cmake/LibXR.CMake, which changes as described below.

• cmake/LibXR.CMake gets two User Code regions, kept on regeneration:

  • CompileOptions, before add_subdirectory(LibXR), for options such as LIBXR_SHARED_BUILD;
  • ApplicationSettings, at the end of the file.

• The first line now mentions the two regions. A file with the earlier first line is still taken as the current format.

• Before writing, the result goes through the same check as the next read. When an existing file has parse errors or malformed, duplicate or unknown User Code markers, the row and column are reported and nothing is written.

• Settings are now edited by CMake syntax instead of regular expressions. Most differences fix wrong output from 6.0.1:

  • SET in upper case no longer gets a second line;
  • a multi-line set no longer leaves a broken last line;
  • text in comments and strings is left alone;
  • a setting added after a multi-line bracket comment no longer lands inside the comment.

  Every difference is listed with its input, old output and new output in the work report and goes into the 6.0.2 release notes.

• Downgrade: libxr 6.0.1 reads a file written by this version as an earlier format and migrates it again, which duplicates sections. BSPs pin the generator version in libxr_config.yaml.

Requires xr-syntax 0.3.0 on PyPI (xrobot-org/xr-syntax#3), so CI installs only after that release. All tests pass locally on Windows with Python 3.13 (628 passed).

[greptile-apps]

Confidence Score: 4/5

[High impact] Upgrades code generation to use external formatting library.

Fix the empty nested setting edit before merging, because regeneration can delete user-written commands.

Findings

1.  User-written blocks get deleted ▶
2.  Value-edit test changes no value ▶

Fix with agent prompt

### Issue 1
src/libxr/generator_stm32_cmake.py:422-424
When a valueless `set(LIBXR_SYSTEM)` sits inside an `if`, `foreach`, or function, `_statement_of` returns the entire enclosing block. This replacement deletes that block and every other command inside it. For example, a block containing `set(LIBXR_SYSTEM )` and `set(KEEP 1)` becomes just `set(LIBXR_SYSTEM None)` on regeneration.

Update only the selected command, and add a test that preserves its surrounding block.

### Issue 2
tests/test_generator_stm32_cmake.py:1053-1056
`test_a_value_is_replaced_without_touching_the_rest_of_the_line` adds a comment to `LIBXR_DRIVER`, then compares the result with an identical string. It never checks the new `_set_system` value edit, so it can pass even if that edit removes comments or changes spacing.

Use a different `LIBXR_SYSTEM` value with a trailing comment, then assert that regeneration changes the value while preserving the comment and spacing.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR moves C++ layout and file assembly to xr-syntax 0.3.0 and uses its CMake frontend to edit LibXR.CMake.

• LibXR.CMake keeps commands in two named User Code regions.
• CMake settings follow parsed commands instead of matching text.
• C++ generators keep their output while using shared xr-syntax tools.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Read LibXR.CMake] --> B[Check parsing and markers]
  B --> C[Extract settings and User Code]
  C --> D[Correct LIBXR_SYSTEM]
  D --> E{Nested setting has no value?}
  E -->|Yes| F[Replace enclosing block]
  E -->|No| G[Edit selected value]
  F --> H[Render and check output]
  G --> H
  H --> I[Write LibXR.CMake]

Loading

_{Reviews (1) · Last reviewed commit: "Read and write LibXR.CMake through the C..." · Reviewed by Greptile}

[greptile-apps]

User-written blocks get deleted

When a valueless set(LIBXR_SYSTEM) sits inside an if, foreach, or function, _statement_of returns the entire enclosing block. This replacement deletes that block and every other command inside it. For example, a block containing set(LIBXR_SYSTEM ) and set(KEEP 1) becomes just set(LIBXR_SYSTEM None) on regeneration.

Update only the selected command, and add a test that preserves its surrounding block.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/libxr/generator_stm32_cmake.py
Line: 422-424

Comment:
**User-written blocks get deleted**

When a valueless `set(LIBXR_SYSTEM)` sits inside an `if`, `foreach`, or function, `_statement_of` returns the entire enclosing block. This replacement deletes that block and every other command inside it. For example, a block containing `set(LIBXR_SYSTEM )` and `set(KEEP 1)` becomes just `set(LIBXR_SYSTEM None)` on regeneration.

Update only the selected command, and add a test that preserves its surrounding block.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Value-edit test changes no value

test_a_value_is_replaced_without_touching_the_rest_of_the_line adds a comment to LIBXR_DRIVER, then compares the result with an identical string. It never checks the new _set_system value edit, so it can pass even if that edit removes comments or changes spacing.

Use a different LIBXR_SYSTEM value with a trailing comment, then assert that regeneration changes the value while preserving the comment and spacing.

Prompt To Fix With AI

This is a comment left during a code review.
Path: tests/test_generator_stm32_cmake.py
Line: 1053-1056

Comment:
**Value-edit test changes no value**

`test_a_value_is_replaced_without_touching_the_rest_of_the_line` adds a comment to `LIBXR_DRIVER`, then compares the result with an identical string. It never checks the new `_set_system` value edit, so it can pass even if that edit removes comments or changes spacing.

Use a different `LIBXR_SYSTEM` value with a trailing comment, then assert that regeneration changes the value while preserving the comment and spacing.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.