Une boucle for qui ne s'exécute qu'une seule fois est un type de bug particulièrement cruel. Elle ne crashe pas. Elle ne lance pas d'erreur. Elle s'exécute, produit une sortie et s'arrête -- vous donnant juste assez de preuves pour penser qu'elle fonctionne tout en retenant le reste. La première itération réussit, créant un faux sentiment de correction. Ce n'est qu'en examinant attentivement les résultats qu'on remarque qu'une boucle sur trois éléments n'a produit qu'un seul résultat.
C'était l'état des boucles for de FLIN le 6 janvier 2026. Il a fallu deux sessions dédiées -- Session 061 et Session 062 -- pour démêler ce qui s'est avéré être deux bugs superposés, chacun se cachant derrière l'autre.
Bug un : le sous-débordement de pile
Le premier symptôme n'était pas du tout subtil. Exécuter toute boucle for produisait un crash par sous-débordement de pile. Le problème était un désaccord de stockage : les variables de boucle stockées directement dans les locales étaient nettoyées par end_scope() comme si elles étaient sur la pile.
La correction a nécessité d'enseigner au compilateur à distinguer les variables de boucle des variables régulières avec un drapeau is_loop_var ajouté à la structure Local.
Bug deux : le problème de la simple itération
La boucle for ne crashait plus, mais elle ne s'exécutait qu'une fois. L'investigation systématique avec du traçage d'opcodes a révélé que les appels de fonctions natives ne nettoyaient pas l'objet fonction de la pile. Après la première itération, la pile contenait l'objet fonction résiduel, et StartFor le prenait pour l'itérateur.
La correction en trois lignes
rustCallInfo::Native { arity: native_arity, index } => {
self.execute_native_call(index)?;
// Remove the function from stack
let result = self.pop()?; // Pop result
self.pop()?; // Pop function object
self.push(result)?; // Push result back
}Trois lignes de logique réelle. La correction était triviale une fois identifiée. L'investigation pour la trouver ne l'était pas.
Le pattern des bugs superposés
La saga de la boucle for est un exemple de manuel de bugs superposés -- plusieurs problèmes indépendants qui interagissent pour produire un seul symptôme visible.
Couche 1 : end_scope() supposait que toutes les variables locales étaient sur la pile. Symptôme : crash.
Couche 2 : Les appels de fonctions natives ne nettoyaient pas l'objet fonction de la pile. Symptôme : la boucle s'exécute une fois.
Couche 3 : L'affectation de variables dans les boucles for avait une erreur de compilation séparée. Symptôme : échec de compilation.
Chaque correction pelait une couche, révélant le problème suivant.
Leçons de débogage
Instrumentez avant d'hypothétiser. Nous avons ajouté du traçage à chaque opcode pertinent et laissé les données raconter l'histoire.
Suivez rigoureusement la discipline de pile. Dans une VM basée sur une pile, chaque instruction qui pousse doit avoir une instruction correspondante qui retire.
Corrigez une chose à la fois. La Session 061 a corrigé le sous-débordement de pile. La Session 062 a corrigé l'itération. Chaque session avait un objectif unique et clair.
La correction en trois lignes est peut-être la meilleure illustration d'une vérité universelle en ingénierie logicielle : la difficulté d'un bug n'est pas proportionnelle à la taille de sa correction, mais à la taille de l'espace de recherche qu'il faut parcourir pour le trouver.
Ceci est la partie 157 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont conçu et construit un langage de programmation à partir de zéro.
Navigation de la série : - [156] L'opcode CreateEntity qui a disparu - [157] Le bug d'itération de la boucle for (vous êtes ici) - [158] Le bug de gestion du None