fix(esp8266): fetch the core from a release asset so submodules come with it

[zackees]

Closes #1380.

The fix

The ESP8266 core was fetched from github.com/esp8266/Arduino/archive/refs/tags/3.1.2.tar.gz — GitHub's auto-generated source archive, which omits submodules by design. The directories are created; the contents are not. Exactly the empty-lib/littlefs/ the issue reported.

Switched to the release asset on the same tag, which bundles them.

Verified before switching rather than assuming — downloaded esp8266-3.1.2.zip and inspected it:

root dirs: {'esp8266-3.1.2'}
littlefs submodule entries: 47
lfs.h present: True

Two things that change and are fine:

• Archive root goes Arduino-3.1.2/ → esp8266-3.1.2/. find_framework_root locates the root by looking for a cores/ subdirectory, not by name.
• Format goes .tar.gz → .zip. extractor.rs already dispatches on extension to extract_zip.

Why this one is worse than a normal missing package

__has_include(<LittleFS.h>) passes in the broken state — the header is present, only the thing it includes is missing. So the failure lands inside the core's own header, past every capability guard a consumer could write. There is no preprocessor test that detects it.

The test asserts shape, not the string

A future version bump must not drift back to /archive/refs/. That is the easy mistake, because every other core in this crate uses that URL form — so the guard checks the form, names the five submodules that would silently empty out, and pins that the asset URL tracks the version const.

Other cores — the issue asks, so I checked

Queried each core URL's repo for .gitmodules at its pinned tag:

core	submodules
esp8266/Arduino@3.1.2	5 — LittleFS/lib/littlefs, SoftwareSerial, ESP8266SdFat, tools/sdk/lwip2/builder, tools/sdk/ssl/bearssl
adafruit/ArduinoCore-samd@1.7.16	2 — libraries/Adafruit_TinyUSB_Arduino, libraries/Adafruit_ZeroDMA
SiliconLabs/arduino@2.2.0	1 — extra/core-api
ArduinoCore-avr, -mbed, -API, ATTinyCore	none

samd carries the same latent failure. Both of its submodules are under libraries/, so a sketch including TinyUSB or ZeroDMA headers breaks identically and just as unguardably.

Not fixed here. It needs its own verification that a bundling artifact actually exists for that core (I have not confirmed one does), and folding an unverified second core into an esp8266 fix would make both harder to review. Reported on the issue as a follow-up.

SiliconLabs/arduino's extra/core-api may or may not be on an include path — unknown, and I did not want to guess.

Verification

• soldr cargo test -p fbuild-library --lib esp8266 — 4 passed
• clippy -D warnings — clean
• release asset contents inspected directly (above)

What I have not done is a real ESP8266 build against the new package — that needs the toolchain download, and the board build will exercise it in CI.

[coderabbitai]

Warning

Review limit reached

Next included review available in 3 minutes.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 54c47775-94a0-4d75-8070-cb2bbb6f5d95

📥 Commits

Reviewing files that changed from the base of the PR and between ea2a8ff and 8b45afb.

📒 Files selected for processing (1)

• crates/fbuild-library/src/library/esp8266_framework.rs

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}