ino prototypes are still emitted above the sketch's #includes on 2.5.15 (#1196 still reproduces) #1275

#1196 was closed on 2026-07-27, but the behaviour it describes still reproduces on fbuild 2.5.15 (released 2026-08-07, eleven days later). Filing separately rather than commenting on a closed issue — happy for this to be folded back into #1196 if that's the better home.

Repro

src/main.ino, with a helper whose return type comes from an included library header:

#include <FastLED.h>
CRGB leds[8];

CRGB kelvinToRGB(uint16_t k) {
  return CRGB(255, k > 5000 ? 255 : 180, k > 5000 ? 200 : 100);
}

void setup() { FastLED.addLeds<WS2812B, 6, GRB>(leds, 8); }
void loop()  { leds[0] = kelvinToRGB(6500); FastLED.show(); }

platformio.ini — platform = atmelavr, board = uno, framework = arduino, FastLED vendored in lib/.

fbuild <dir> build -e arduino_avr_uno

Result

error: 'CRGB' does not name a type; did you mean 'OCR0B'?

The generated .fbuild/build/arduino_avr_uno/release/src/main.ino.cpp:

 1  #include <Arduino.h>
 2  // Auto-generated function prototypes
 3  CRGB kelvinToRGB(uint16_t k);      <-- CRGB not declared yet
 4
 5  #line 1 "src/main.ino"
 6  #include <FastLED.h>               <-- declared here
 7  CRGB leds[8];
 8
 9  CRGB kelvinToRGB(uint16_t k) {

The prototype at line 3 still precedes the sketch's own #include at line 6.

Note on scope

#1196's example used a sketch-defined type (struct MyStruct). This case is a type from an #included library header, which may be a distinct path through preprocess_ino_files — the prototype block still lands above the include block, which is the part #1196 says should move ("arduino-cli avoids this by inserting prototypes after the include block").

So it's possible the fix addressed sketch-defined types specifically and this variant slipped through, rather than the fix regressing outright.

Context

Found while integrating fbuild into Design Studio for FastLED. Our helper works around this by writing the generated sketch as main.cpp with #include <Arduino.h> prepended instead of main.ino, which skips ino preprocessing entirely — so we're unblocked. Reporting because we'd like to drop that workaround, and because it bites any sketch with a FastLED-typed helper.