fix(acceptance): #223 stm32 SPI + teensyLC LTO-symbol probes#226
fix(acceptance): #223 stm32 SPI + teensyLC LTO-symbol probes#226
Conversation
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Two pre-existing acceptance gates failed for the same reason: under each orchestrator's Release profile (`-flto -Os` + `--gc-sections`) the test was probing for a symbol the linker had inlined and stripped. Both fixes broaden the probe to also accept an LTO-stable signal that proves the intended code was actually linked. stm32f103c8 SPI auto-discovery (#223): - crates/fbuild-build/tests/stm32_acceptance.rs:99 — accept either the mangled `_ZN8SPIClass*` symbol (non-LTO builds) OR a `PinMap_SPI_*` global from `Arduino_Core_STM32/libraries/SPI/src/utility/spi_com.c` (LTO builds; address-taken `const` array survives `--gc-sections`). Either signal proves the SPI library was auto-discovered, compiled, and linked. Orchestrator wiring is unchanged — already correct since #214 (commit 86bb2d9). teensyLC blink (acceptance-205 baseline failure since 2026-04-25): - crates/fbuild-build/tests/teensylc_acceptance.rs:88 — accept the unmangled `setup`/`loop`, the mangled `_Z5setupv`/`_Z4loopv`, OR the sketch's `Serial.println` literal `"Teensy LC Test - LED Blink"` in the firmware bytes. Strings in `.rodata` survive `--gc-sections` because their address is taken by the println call. - crates/fbuild-build/tests/teensylc_acceptance.rs:114 — use `result.compile_database_path` from the BuildResult instead of walking `params.build_dir` (which the pipeline ignores: it roots its cache at `<project_dir>/.fbuild/build/<env>/<profile>/`). Verified locally on Windows host (toolchain + packages cached): both acceptance tests pass under Release LTO. Closes #223 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
9835765 to
155e543
Compare
Two pre-existing
acceptance-205.ymlgates failed for the same reason: under each orchestrator's Release profile (-flto -Os+--gc-sections) the test was probing for a symbol the linker had inlined and stripped. Both fixes broaden the probe to also accept an LTO-stable signal that proves the intended code actually linked.stm32f103c8 SPI auto-discovery — closes #223
crates/fbuild-build/tests/stm32_acceptance.rs:99— accept either the mangled_ZN8SPIClass*symbol (non-LTO) or aPinMap_SPI_*global fromArduino_Core_STM32/libraries/SPI/src/utility/spi_com.c(LTO; address-takenconstarray survives--gc-sections).86bb2d9).teensyLC blink —
acceptance-205.ymlbaseline failure since 2026-04-25Same root-cause family: tiny
setup()/loop()are visible in the LTO unit alongside Teensyduino'smain.cppand get inlined intomain, with both unmangled and mangled symbols stripped. The original assertion (setupor_Z5setupv) is incompatible with the orchestrator's Release LTO settings.crates/fbuild-build/tests/teensylc_acceptance.rs:88— accept any of three signals: unmangledsetup/loop, mangled_Z5setupv/_Z4loopv, or the sketch'sSerial.println("Teensy LC Test - LED Blink")literal present in the firmware bytes (strings in.rodatasurvive--gc-sectionsbecause their address is taken by the println call).crates/fbuild-build/tests/teensylc_acceptance.rs:114— useresult.compile_database_pathfromBuildResultinstead of walkingparams.build_dir. The pipeline ignoresparams.build_dirand roots its cache at<project_dir>/.fbuild/build/<env>/<profile>/, so the previous walk-based lookup never foundcompile_commands.json. The orchestrator already reports the effective path — trust it.Test plan
uv run soldr cargo test -p fbuild-build --release --test stm32_acceptance -- --ignored stm32f103c8_blink_with_spi_auto_discovers_library_205_ac4passes locallyuv run soldr cargo test -p fbuild-build --release --test teensylc_acceptance -- --ignored teensylc_blink_meets_205_acceptance_criteriapasses locallyuv run soldr cargo clippy --workspace --all-targets -- -D warningscleanuv run soldr cargo fmt --allcleanacceptance-205.ymlSTM32 gate goes greenacceptance-205.ymlteensyLC gate goes green (first time green since 2026-04-25)Closes #223