En plus de toutes les bonnes réponses à ce jour:
Vous avez un "biais d'observateur". Vous n'observez pas de bugs et vous supposez donc qu'il n'y en a pas.
Je pensais comme toi. Ensuite, j'ai commencé à écrire des compilateurs de manière professionnelle, et laissez-moi vous dire qu'il y a beaucoup de bugs là-dedans!
Vous ne voyez pas les bogues parce que vous écrivez un code équivalent à 99,999% du reste du code écrit. Vous écrivez probablement du code parfaitement normal, simple et clairement correct, qui appelle des méthodes et exécute des boucles sans rien faire de bizarre ou bizarre, car vous êtes un développeur normal qui résout des problèmes commerciaux normaux.
Vous ne voyez pas de bogues de compilateur, car ceux-ci ne figurent pas dans les scénarios de code normaux simples à analyser et faciles à analyser; les bugs sont dans l'analyse de code étrange que vous n'écrivez pas.
J'ai par contre le biais d'observateur opposé. Je vois du code fou toute la journée, et donc pour moi, les compilateurs semblent fourmiller de bogues.
Si vous vous assoyiez avec la spécification de langue de n'importe quel langage et preniez n'importe quelle implémentation de compilateur pour ce langage, et essayiez vraiment de déterminer si le compilateur implémentait exactement la spécification ou non, en vous concentrant sur des cas obscurs, vous découvririez bientôt compilateur des bogues assez fréquemment. Laissez-moi vous donner un exemple, voici un bogue du compilateur C # que j'ai trouvé littéralement il y a cinq minutes.
static void N(ref int x){}
...
N(ref 123);
Le compilateur donne trois erreurs.
- Un argument ref ou out doit être une variable assignable.
- La meilleure correspondance pour N (ref int x) comporte des arguments non valides.
- "Ref" manquant dans l'argument 1.
De toute évidence, le premier message d'erreur est correct et le troisième est un bogue. L'algorithme de génération d'erreur essaie de comprendre pourquoi le premier argument était invalide, il l'examine, voit qu'il s'agit d'une constante et ne retourne pas dans le code source pour vérifier s'il a été marqué "ref"; il suppose plutôt que personne ne serait assez idiot pour marquer une constante comme arbitre et décide que l'arbitre doit être manquant.
Le troisième message d'erreur correct n'est pas clair, mais ce n'est pas ça. En fait, il n'est pas clair si le deuxième message d'erreur est correct non plus. La résolution de surcharge doit-elle échouer ou "ref 123" doit-il être traité comme un argument de référence du type correct? Je vais maintenant devoir y réfléchir et en discuter avec l'équipe de triage afin que nous puissions déterminer quel est le bon comportement.
Vous n'avez jamais vu ce bug parce que vous ne feriez probablement jamais quelque chose d'aussi stupide que d'essayer de passer 123 par réf. Et si vous le faisiez, vous ne remarqueriez probablement même pas que le troisième message d'erreur est absurde, car le premier message est correct et suffisant pour diagnostiquer le problème. Mais j'essaie de faire des choses comme ça, parce que j'essaye de casser le compilateur. Si vous essayiez, vous verriez aussi les bugs.