Apporter de petites modifications à une bibliothèque de bas niveau sans casser son API publique

## Garder les changements petits et ne toucher l’API et l’ABI publiques que sur demande Traitez une interface publique stable de programmation d'applications et une interface binaire d'application comme des contraintes strictes. ### Avant Modification - Lisez la documentation du dépôt sur la compilation, les tests, la configuration, les contributions et la publication avant tout travail non trivial. - Identifiez l'unique sous-système ou sujet responsable de la modification demandée. - Respectez les conventions locales de chaque fichier modifié. - Préservez les modifications sans rapport apportées par l'utilisateur et les artefacts non suivis. ### Limites des Modifications - Préférez des différences minimales et des modifications de suivi progressives aux réécritures étendues. - Ne renommez, ne réorganisez, ne reformatez et ne nettoyez pas le code sans rapport. - N'ajoutez pas de nouvelle interface publique sauf demande explicite. - Ne modifiez ni ne retirez une interface publique ou un contrat binaire existant sauf demande explicite. - Préservez le comportement des fonctions optionnelles, les compilations à fonctions réduites et les protections conditionnelles de compilation. - Ne modifiez pas silencieusement les valeurs de compilation ou de fonctions par défaut. Lorsqu'un code apparemment maladroit se trouve sur une limite de compatibilité, supposez qu'il peut traiter un véritable cas limite jusqu'à ce que les tests, l'historique et le comportement environnant prouvent le contraire. ## Compiler avec le flux standard et lancer les tests du sous-système modifié Utilisez le flux standard du dépôt pour configurer, compiler et tester avant de vous fier à des contrôles spécialisés. ### Séquence par Défaut 1. Configurez ou reconfigurez le répertoire de compilation désigné. 2. Compilez les cibles concernées. 3. Exécutez la suite de tests adaptée à l'étape actuelle. 4. Confirmez que la compilation n'introduit aucun nouvel avertissement. Si le répertoire de compilation n'existe pas encore, effectuez une configuration initiale plutôt qu'une opération réservée à la reconfiguration. Recompilez les cibles modifiées après chaque modification substantielle du code. ### Contrôles Ciblés Minimaux - Pour la logique de transformation ou de mise en forme du texte, exécutez sa suite dédiée de tests de comportement. - Pour les travaux de réduction, de création de sous-ensembles ou de graphes, exécutez la suite correspondante du sous-système. - Pour les travaux sur les interfaces publiques, exécutez la suite de tests de l'interface de programmation d'applications. - Pour les travaux sur un outil en ligne de commande, recompilez l'outil concerné et exercez-le sur un petit échantillon représentatif. - Pour une correction de défaut ou un renforcement d'analyseur, ajoutez ou actualisez, lorsque c'est possible, le test de régression, l'entrée de test aléatoire, la cible de test aléatoire ou le résultat attendu le plus proche. Les contrôles ciblés accélèrent les itérations, mais ne remplacent pas une validation plus large lorsque le comportement partagé ou la préparation à la publication sont concernés. ## Choisir où modifier le code selon le sous-système et suivre les habitudes du projet Comprenez les responsabilités adjacentes avant de choisir où modifier le code. ### Limites de Responsabilité - Séparez le comportement de la bibliothèque principale des outils installés, des mesures de performance, de la documentation, des liaisons de langage et des composants expérimentaux. - Traitez les auxiliaires de graphe comme une partie du processus de réduction lorsqu'ils participent à son comportement. - Pour les unités de traduction trop volumineuses de rastérisation, de vecteurs, de graphismes ou de domaines similaires, préférez extraire des auxiliaires ciblés et diviser par responsabilité plutôt qu'ajouter davantage de branches. - Pour une intégration de langage, examinez à la fois la définition native de compilation et le manifeste du paquet de langage avant de modifier l'intégration de compilation. ### Conventions Existantes - Utilisez les modèles établis du projet pour l'allocation, les erreurs, la prédiction de branchement, l'objet nul, les conteneurs et les utilitaires. - Préférez les abstractions du projet aux primitives brutes de la plateforme lorsqu'elles intègrent un comportement de portabilité ou de sécurité. - N'introduisez pas de bibliothèque externe de conteneurs dans le code principal lorsque le projet possède déjà des conteneurs et utilitaires établis. - Ajoutez la documentation de l'interface publique à l'emplacement habituel du dépôt, dans le code source ou la documentation. Centralisez la logique dupliquée d'analyse, de cache ou d'assistance lorsque la duplication commence à se répandre, mais ne transformez pas une correction limitée en réécriture architecturale sans rapport. ## Échouer proprement face aux erreurs mémoire et aux entrées hostiles sur toutes les plateformes Traitez les échecs d'allocation, les entrées hostiles, la diversité des compilateurs et les compilations à fonctions réduites comme des parties normales de la surface prise en charge. ### Sécurité de l'Allocation et de l'Analyseur - Suivez les modèles existants d'allocation et de gestion des erreurs afin que le nouveau code échoue de manière sûre sous pression mémoire. - Examinez les protections existantes de l'analyseur et l'infrastructure de tests aléatoires avant de renforcer le traitement des entrées. - Lors d'un échec d'allocation provoqué, le résultat minimal acceptable est l'absence de plantage, d'accès hors limites et de corruption de mémoire. - Pour les composants expérimentaux, un échec anticipé au mieux est acceptable sous pression mémoire. - N'ajoutez pas de logique complexe de retour en arrière uniquement pour préserver un travail partiel après un échec d'allocation, sauf si le contrat du composant l'exige. ### Portabilité - Traitez les régressions de compilateur, de système d'exploitation, de largeur d'architecture, de compilation croisée et de compilation à fonctions réduites comme de véritables défauts. - Validez les hypothèses sur l'ensemble des chaînes d'outils et des largeurs d'entiers prises en charge par le projet. - Continuez d'exercer réellement les protections de fonctions à la compilation et les chemins de repli. - Lors de la simplification de code de bas niveau, vérifiez si la complexité initiale gérait l'alignement, le dépassement, la durée de vie, l'aliasage ou le comportement propre à la plateforme. Préférez une régression reproductible à une modification qui ne fait que corriger le problème sans pouvoir démontrer la défaillance initiale. ## Régénérer les tables générées depuis leur générateur au lieu de les modifier à la main Maintenez chaque description de compilation et chaque résultat généré synchronisés avec la modification du code source. ### Modifications du Système de Compilation - Actualisez ensemble les options, les résumés de configuration, les outils installés, les tests et les cibles dépendantes. - Si l'empaquetage ou la compilation croisée sont concernés, examinez tous les systèmes de compilation pris en charge au lieu de modifier uniquement le principal. - Préservez les valeurs par défaut des options, sauf si la tâche exige explicitement une modification de valeur par défaut. - Validez à la fois les formes activées et désactivées des fonctions optionnelles concernées. ### Données Générées - Modifiez le générateur, les données sources ou la chaîne d'automatisation de compilation, puis régénérez les résultats. - Ne modifiez pas manuellement les tableaux ou index générés, sauf exigence explicite de la tâche. - Ne supposez pas que les résultats générés, les ressources locales de test, les polices ou les artefacts non suivis sont jetables. - Examinez les différences régénérées afin de détecter une portée inattendue ou des modifications non déterministes. Si une modification du générateur concerne des données publiques ou des attentes de test, actualisez les tests et la documentation associés dans la même modification limitée. ## N’ajouter d’API publique que sur demande, avec marqueur de version et documentation Traitez le comportement visible par l'utilisateur comme une modification coordonnée du code, de la documentation, du versionnage et de l'intégration de compilation. ### Contrôle des Interfaces Publiques - Conservez les déclarations publiques dans les en-têtes ou modules publics désignés, et non dans les fichiers internes de mise en œuvre. - Ajoutez une nouvelle surface publique uniquement lorsque la demande l'autorise explicitement. - Lorsqu'une nouvelle interface est autorisée, ajoutez le marqueur de version et l'entrée de notes de publication exigés par le dépôt. - Actualisez les index de sections générés, les manifestes de documentation ou les listes de références au moyen de leur flux approuvé. - Préservez l'organisation binaire, la visibilité des symboles, les conventions d'appel et la compatibilité du code source, sauf approbation explicite d'une modification incompatible. ### Comportement Visible par l'Utilisateur - Actualisez la documentation concernée lorsqu'une fonction devient visible par l'intermédiaire d'une bibliothèque ou d'un outil installé. - Maintenez l'installation et l'intégration de compilation synchronisées avec le comportement nouvellement exposé. - Placez la documentation des interfaces publiques et les index générés là où les pratiques locales l'exigent. - Ne désactivez pas un test en échec dans le seul but d'obtenir une exécution réussie ; documentez une exception justifiée et ses conséquences. ## Trouver d’abord la cause et faire le commit sans pousser vers le dépôt distant Prouvez la cause et le résultat avant de présenter une modification comme achevée. ### Méthode de Travail 1. Reproduisez le problème lorsque cela est possible. 2. Comprenez la cause profonde avant d'écrire la correction. 3. S'il reste une ambiguïté importante, posez une question au lieu de deviner. 4. Examinez l'historique avant de simplifier un code qui paraît inhabituellement complexe. 5. Ajoutez ou actualisez la couverture de régression la plus proche. 6. Validez le sous-système modifié, les configurations concernées et le comportement plus large. ### Règles d'Enregistrement - Exécutez la suite de tests complète avant d'enregistrer du code, de la logique de compilation, des résultats générés ou des entrées de test. - Les modifications limitées à la documentation ou à l'intégration continue peuvent omettre les tests complets uniquement lorsqu'elles ne peuvent pas concerner ces domaines ; signalez cette omission. - Limitez chaque enregistrement à un seul problème ou sujet. - N'envoyez jamais de modifications vers le dépôt distant ; laissez l'envoi à la personne autorisée. - Utilisez le préfixe de sous-système, les lignes finales d'attribution et les conventions de message du dépôt. - Pour un message d'enregistrement sur plusieurs lignes, utilisez un fichier ou une saisie fournie par un éditeur plutôt que des séquences d'échappement de saut de ligne. - Décrivez la cause profonde, la correction et les tests uniquement lorsque le travail réellement effectué les étaye. Lors de la transmission, indiquez le périmètre modifié, les tests exécutés, les avertissements, les configurations non prises en charge, les risques non résolus et toute validation non effectuée.