<\/span><\/p>\n Cet article traite d’un aspect tr\u00e8s important du travail de tout d\u00e9veloppeur\u00a0: combien de temps faut-il pour effectuer un test (ou juste atteindre la premi\u00e8re ligne de votre programme) apr\u00e8s avoir effectu\u00e9 une modification dans le code.<\/em> C’est ce qu’on appelle le temps de test<\/strong>.<\/p>\n Pourquoi est-ce si important\u00a0:<\/p>\n On peut consid\u00e9rer que les deux situations ont leurs avantages et leurs inconv\u00e9nients, mais je pense qu’il est pr\u00e9f\u00e9rable de faire des pauses quand vous le souhaitez et non lorsque votre compilateur vous l’impose. Les compilateurs sont des logiciels intelligents, mais pas au point de pouvoir d\u00e9finir les meilleurs horaires de travail pour les humains.<\/p>\n En tant que d\u00e9veloppeurs, nous sommes g\u00e9n\u00e9ralement plus satisfaits lorsque nous nous sentons productifs<\/strong>. Les pauses dues \u00e0 la compilation interrompent le flow et nous donnent l’impression d’\u00eatre bloqu\u00e9s, stopp\u00e9s dans notre \u00e9lan, improductifs. Peu de gens appr\u00e9cient cela.<\/p>\n Il y a g\u00e9n\u00e9ralement trois raisons principales pour lesquelles les temps de compilation sont longs\u00a0:<\/p>\n Les deux premiers facteurs \u00e9tant assez \u00e9vidents, parlons plut\u00f4t du troisi\u00e8me\u00a0: l’intelligence du compilateur. Avec Kotlin, nous avons opt\u00e9 pour un code lisible, propre et s\u00fbr. Cela implique que le compilateur puisse \u00eatre assez intelligent, et voici pourquoi.<\/p>\n Kotlin est con\u00e7u pour \u00eatre utilis\u00e9 dans un cadre “industriel”, pour des projets qui ont une longue dur\u00e9e de vie, \u00e9voluent et impliquent beaucoup de monde. Nous voulons donc une s\u00e9curit\u00e9 de type statique pour d\u00e9tecter rapidement les bugs et disposer d’outils pr\u00e9cis (saisie semi-automatique, refactorisations, recherche d’utilisations dans l’EDI, navigation pr\u00e9cise dans le code, etc.). Nous souhaitons \u00e9galement avoir un code propre et lisible, sans “bruit” inutile. C’est pourquoi, entre autres, nous ne voulons pas de types partout dans le code et avons des algorithmes d’inf\u00e9rence de type et de r\u00e9solution de surcharge intelligents qui prennent en charge les fonctions de types lambdas et extensions, la conversion intelligente (typage bas\u00e9 sur le flux), etc. Dans le m\u00eame temps, le compilateur Kotlin trouve un grand nombre d’\u00e9l\u00e9ments par lui-m\u00eame pour garder le code propre.<\/p>\n Pour qu’un compilateur intelligent fonctionne rapidement, vous devez imp\u00e9rativement optimiser chaque \u00e9l\u00e9ment de la cha\u00eene d’outils, et c’est un \u00e9l\u00e9ment sur lequel nous travaillons en permanence. Nous travaillons entre autres sur un compilateur Kotlin nouvelle g\u00e9n\u00e9ration qui fonctionnera beaucoup plus vite que le compilateur actuel. Mais il ne s’agit pas de cela dans cet article.<\/p>\n Aussi rapide que soit un compilateur, il ne sera jamais trop rapide pour un gros projet. Et recompiler l’ensemble de la base de code sur chaque petit changement effectu\u00e9 pendant le d\u00e9bogage repr\u00e9sente une perte de temps \u00e9norme. Nous essayons donc de r\u00e9utiliser autant que possible les compilations pr\u00e9c\u00e9dentes et de ne compiler que lorsque c’est absolument n\u00e9cessaire.<\/p>\n Il y a principalement deux approches pour r\u00e9duire la quantit\u00e9 de code \u00e0 recompiler\u00a0:<\/p>\n (On pourrait penser \u00e0 une approche encore plus pr\u00e9cise qui permettrait de suivre les changements dans les fonctions ou les classes individuelles et donc de recompiler encore moins qu’un fichier, mais je ne vois pas de mise en \u0153uvre pratique pour une telle approche dans les langages industriels, et dans l’ensemble cela ne semble pas n\u00e9cessaire.)<\/p>\n Examinons maintenant plus en d\u00e9tail les deux approches.<\/p>\n Cette approche consiste principalement \u00e0\u00a0:<\/p>\n L’algorithme est plus ou moins facile \u00e0 comprendre si vous savez comment comparer les ABI. Sinon, il faut recompiler les modules qui ont \u00e9t\u00e9 affect\u00e9s par les modifications. Bien entendu, une modification d’un module dont personne ne d\u00e9pend se compilera plus rapidement qu’une modification dans le module \u00ab\u00a0util\u00a0\u00bb dont tout le monde d\u00e9pend (si cela affecte son ABI).<\/p>\n Une ABI (interface binaire d’application) \u00e9quivaut \u00e0 une API mais pour les binaires. L’ABI est la seule partie du binaire qui int\u00e9resse les modules d\u00e9pendants (Kotlin ayant une compilation s\u00e9par\u00e9e<\/em>, mais nous n’aborderons pas ce point ici). <\/p>\n En gros, un binaire Kotlin (que ce soit un fichier de classe JVM ou un KLib) contient des d\u00e9clarations et des corps de fonctions. D’autres modules peuvent r\u00e9f\u00e9rencer des d\u00e9clarations, mais pas toutes les d\u00e9clarations. Ainsi, les classes priv\u00e9es et les membres, par exemple, ne font pas partie de l’ABI. Un corps de fonction peut-il faire partie d’une ABI\u00a0? Oui, si ce corps est inline \u00e0 l’endroit de l’appel. Kotlin dispose de fonctions inline et de constantes de temps de compilation (\u00ab\u00a0const\u00a0val\u00a0\u00bb). Si un corps d’une fonction inline ou une valeur d’une constante change, il peut \u00eatre n\u00e9cessaire de recompiler les modules d\u00e9pendants.<\/p>\n Ainsi, l’ABI d’un module Kotlin est constitu\u00e9 de d\u00e9clarations, de corps de fonctions inline et de valeurs \u00ab\u00a0const val\u00a0\u00bb visibles \u00e0 partir d’autres modules.<\/p>\n Pour d\u00e9tecter facilement une modification de l’ABI\u00a0:<\/p>\n Le principal avantage de l’\u00e9vitement de compilation est sa relative simplicit\u00e9.<\/p>\n Cette approche est vraiment utile lorsque les modules sont petits, car l’unit\u00e9 de recompilation est un module entier. Pour les gros modules, les recompilations seront longues. \u00c9viter la compilation requiert donc d’avoir un nombre important de petits modules et ce n’est pas forc\u00e9ment ce qu’un d\u00e9veloppeurs veut. Les petits modules ne sont pas n\u00e9cessairement mal con\u00e7us, mais je pr\u00e9f\u00e8re structurer mon code pour les personnes et non pour les machines.<\/p>\n Par ailleurs, de nombreux projets ont un module \u00ab\u00a0util\u00a0\u00bb qui comprend de nombreuses petites fonctions utiles. Et pratiquement tous les autres modules d\u00e9pendent de ce module \u00ab\u00a0util\u00a0\u00bb, au moins de fa\u00e7on transitoire. Supposons maintenant que je veuille ajouter une autre petite fonction utile qui est utilis\u00e9e trois fois dans ma base de code. Elle s’ajoute au module ABI, tous les modules d\u00e9pendants sont affect\u00e9s et je me retrouve \u00e0 attendre car tout mon projet est recompil\u00e9.<\/p>\n De plus, en ayant beaucoup de petits modules (chacun d’eux d\u00e9pendant de plusieurs autres) la configuration de mon projet peut devenir \u00e9norme car chaque module comporte un ensemble unique de d\u00e9pendances (sources et binaires). La configuration de chaque module dans Gradle prend normalement entre 50 et 100\u00a0ms. Il n’est pas rare que les grands projets comportent plus de 1\u00a0000\u00a0modules, le temps total de configuration peut alors largement d\u00e9passer une minute. Et la configuration doit \u00eatre ex\u00e9cut\u00e9e pour chaque build et \u00e0 chaque fois que le projet est import\u00e9 dans l’EDI (par exemple lorsqu’une nouvelle d\u00e9pendance est ajout\u00e9e). <\/p>\n Un certain nombre de fonctionnalit\u00e9s de Gradle att\u00e9nuent quelques-uns des inconv\u00e9nients li\u00e9s \u00e0 l’\u00e9vitement de compilation\u00a0: par exemple, les configurations peuvent \u00eatre mises en cache. Cependant, la marge d’am\u00e9lioration reste encore assez importante et c’est pourquoi nous utilisons la compilation incr\u00e9mentale dans Kotlin.<\/p>\n La compilation incr\u00e9mentale est une approche plus granulaire que l’\u00e9vitement de compilation : elle s’applique aux fichiers individuels plut\u00f4t qu’aux modules. En cons\u00e9quence, elle ne se pr\u00e9occupe pas de la taille des modules et ne recompile pas l’ensemble du projet lorsqu’un ABI d’un module \u00ab\u00a0populaire\u00a0\u00bb est modifi\u00e9 de mani\u00e8re insignifiante. En g\u00e9n\u00e9ral, cette approche est moins restrictive pour l’utilisateur et r\u00e9duit le temps de test. Les d\u00e9veloppeurs sont ainsi moins enclins \u00e0 se lancer dans des combats l’\u00e9p\u00e9e.<\/p>\n La compilation incr\u00e9mentale est depuis toujours prise en charge par JPS, le syst\u00e8me de build int\u00e9gr\u00e9 d’IntelliJ. Gradle ne prend en charge que les \u00e9vitements de compilation par d\u00e9faut. \u00c0 partir de la version 1.4, le plugin Kotlin Gradle apporte \u00e0 Gradle une impl\u00e9mentation quelque peu limit\u00e9e de la compilation incr\u00e9mentale et la marge de progression est encore importante.<\/p>\n Id\u00e9alement, il suffirait d’examiner les fichiers modifi\u00e9s, de d\u00e9terminer exactement quels fichiers en d\u00e9pendent et de recompiler tous ces fichiers. Cela peut sembler facile, mais en r\u00e9alit\u00e9, il n’est pas du tout \u00e9vident de d\u00e9terminer avec pr\u00e9cision cet ensemble de fichiers d\u00e9pendants. En effet, il peut y avoir des d\u00e9pendances circulaires entre les fichiers sources, ce qui n’est pas autoris\u00e9 pour les modules dans la plupart des syst\u00e8mes de build modernes. De plus, les d\u00e9pendances des fichiers individuels ne sont pas d\u00e9clar\u00e9es explicitement. Notez que les importations ne sont pas suffisantes pour d\u00e9terminer les d\u00e9pendances en raison des r\u00e9f\u00e9rences au m\u00eame paquet et aux m\u00eames appels de cha\u00eene\u00a0: pour A.b.c(), nous devons importer au maximum A, mais les changements au niveau de B nous affecteront \u00e9galement. <\/p>\n En raison de toutes ces complications, la compilation incr\u00e9mentale tente de d\u00e9terminer approximativement l’ensemble des fichiers concern\u00e9s en proc\u00e9dant en plusieurs cycles qui consistent \u00e0\u00a0:<\/p>\n Comme nous savons d\u00e9j\u00e0 comment comparer les ABI, il n’y a en fait que deux probl\u00e8mes qui peuvent se poser\u00a0:<\/p>\n Les deux sont au moins en partie des fonctionnalit\u00e9s de la compilation incr\u00e9mentale de Kotlin. Examinons-les plus en d\u00e9tail.<\/p>\n Le compilateur sait comment utiliser un sous-ensemble des r\u00e9sultats de la compilation pr\u00e9c\u00e9dente afin d’\u00e9viter la compilation des fichiers n’ayant \u00e9t\u00e9 modifi\u00e9s depuis (non dirty files) et de charger seulement les symboles d\u00e9finis dans ces derniers pour produire les binaires pour les fichiers ayant \u00e9t\u00e9 modifi\u00e9s (dirty files). Un compilateur ne serait pas forc\u00e9ment capable de faire cela en l’absence d’incr\u00e9mentalit\u00e9\u00a0: produire un gros binaire \u00e0 partir d’un module au lieu d’un petit binaire par fichier source n’est pas si courant en dehors du monde de la JVM. Et il ne s’agit pas d’une fonctionnalit\u00e9 du langage Kotlin, c’est un d\u00e9tail de l’impl\u00e9mentation de la compilation incr\u00e9mentale.<\/p>\n En comparant les ABI des fichiers ayant \u00e9t\u00e9 modifi\u00e9s aux r\u00e9sultats pr\u00e9c\u00e9dents, nous pouvons d\u00e9couvrir que nous avons de la chance et qu’aucun autre cycle de recompilation n’est n\u00e9cessaire. Voici quelques exemples de modifications qui requi\u00e8rent seulement la recompilation des fichiers ayant \u00e9t\u00e9 modifi\u00e9s (dirty files) car l’ABI n’est pas affect\u00e9e :<\/p>\n Comme vous pouvez le constater, ces cas sont assez fr\u00e9quents lors du d\u00e9bogage et de l’am\u00e9lioration it\u00e9rative du code.<\/p>\n Si nous ne sommes pas tr\u00e8s chanceux et qu’une d\u00e9claration a \u00e9t\u00e9 modifi\u00e9e, certains fichiers qui d\u00e9pendent de ceux qui ont \u00e9t\u00e9 modifi\u00e9s pourraient produire des r\u00e9sultats diff\u00e9rents lors de la recompilation, m\u00eame lorsque aucune ligne de leur code n’a \u00e9t\u00e9 modifi\u00e9e.<\/p>\n La strat\u00e9gie la plus simple serait d’abandonner \u00e0 ce stade et de recompiler tout le module. Cela met en \u00e9vidence tous les probl\u00e8mes li\u00e9s \u00e0 l’\u00e9vitement de compilation\u00a0: les modules volumineux qui deviennent probl\u00e9matiques d\u00e8s que vous modifiez une d\u00e9claration et de nombreux petits modules qui ont \u00e9galement un co\u00fbt en terme de performance, comme d\u00e9crit plus haut. Il faut donc avoir une approche plus granulaire\u00a0: trouver les fichiers concern\u00e9s et les recompiler.<\/p>\n Nous voulons donc identifier les fichiers qui d\u00e9pendent des parties de l’ABI qui ont effectivement chang\u00e9. Par exemple, si l’utilisateur a renomm\u00e9 Id\u00e9alement, pour chaque fichier, nous devrions stocker les fichiers qui en d\u00e9pendent et les parties de l’ABI qui les int\u00e9ressent. En pratique, il est trop co\u00fbteux de stocker toutes les d\u00e9pendances avec autant de pr\u00e9cision. Et dans de nombreux cas, il est inutile de conserver des signatures compl\u00e8tes.<\/p>\n Prenons cet exemple\u00a0:<\/p>\n Fichier\u00a0: dirty.kt<\/strong><\/p>\n Fichier\u00a0: clean.kt<\/strong><\/p>\n Supposons que l’utilisateur ait renomm\u00e9 la fonction Nous commen\u00e7ons par recompiler le fichier modifi\u00e9\u00a0: dirty.kt. Nous constatons ensuite que quelque chose a chang\u00e9 dans l’ABI\u00a0:<\/p>\n Nous constatons maintenant que clean.kt d\u00e9pend du nom La compilation incr\u00e9mentale doit produire le m\u00eame r\u00e9sultat qu’une recompilation compl\u00e8te de toutes les sources. Consid\u00e9rez le type de retour du nouveau La r\u00e8gle majeure de la compilation incr\u00e9mentale pour Kotlin\u00a0est : ne faites confiance qu’aux noms<\/strong>. Et c’est pourquoi pour chaque fichier, nous stockons\u00a0:<\/p>\n Certaines optimisations sont possibles dans la fa\u00e7on dont nous stockons tout cela. Par exemple, certains noms ne sont jamais recherch\u00e9s en dehors du fichier, comme les noms des variables locales et, dans certains cas, des fonctions locales. Nous pourrions donc les exclure de l’index. Pour affiner l’algorithme, nous enregistrons les fichiers qui ont \u00e9t\u00e9 consult\u00e9s lors de la recherche de chacun des noms. Et pour compresser l’index, on utilise le hachage. Il est possible d’apporter d’autres am\u00e9liorations.<\/p>\n Comme vous l’avez sans doute remarqu\u00e9, nous devons recompiler plusieurs fois l’ensemble de fichiers qui ont \u00e9t\u00e9 modifi\u00e9s. Il n’y a malheureusement pas d’autre solution\u00a0: il peut y avoir des d\u00e9pendances circulaires et seule la compilation de tous les fichiers concern\u00e9s en une seule fois donnera un r\u00e9sultat correct. Dans le pire des cas, la compilation incr\u00e9mentale peut faire plus que l’\u00e9vitement de compilation, il devrait donc y avoir des heuristiques en place pour l’\u00e9viter.<\/p>\n La compilation incr\u00e9mentale peut d\u00e9passer les limites des modules.<\/p>\n Supposons que nous ayons des fichiers qui ont \u00e9t\u00e9 modifi\u00e9s dans un module, que nous fassions quelques tests et que nous atteignions un point fixe. Nous avons maintenant la nouvelle ABI de ce module et nous devons faire quelque chose pour les modules d\u00e9pendants.<\/p>\n Bien s\u00fbr, nous savons quels noms ont \u00e9t\u00e9 affect\u00e9s dans l’ABI de notre module initial et quels fichiers dans les modules d\u00e9pendants ont recherch\u00e9 ces noms. Nous pourrions appliquer essentiellement le m\u00eame algorithme incr\u00e9mental mais en partant du changement d’ABI et non d’un ensemble de dirty files. Au fait, s’il n’y a pas de d\u00e9pendances circulaires entre les modules, il suffit de recompiler les fichiers d\u00e9pendants seuls. Mais si leur ABI a chang\u00e9, il faudra ajouter d’autres fichiers du m\u00eame module \u00e0 l’ensemble et recompiler de nouveau les m\u00eames fichiers.<\/p>\n Impl\u00e9menter ceci dans Gradle repr\u00e9sente un v\u00e9ritable d\u00e9fi. Il faudra probablement apporter quelques modifications \u00e0 l’architecture de Gradle, mais nous savons par exp\u00e9rience que c’est possible et bien accueilli par l’\u00e9quipe Gradle.<\/p>\n Mon but ici \u00e9tait de vous donner un aper\u00e7u de la fascinante machinerie de la compilation rapide pour Kotlin. Il y a beaucoup d’autres \u00e9l\u00e9ments \u00e0 prendre en compte que j’ai d\u00e9lib\u00e9r\u00e9ment laiss\u00e9s de c\u00f4t\u00e9, notamment\u00a0<\/p>\n Maintenant, vous avez une meilleure id\u00e9e des d\u00e9fis de la compilation rapide dans un langage de programmation moderne. Notez que certains langages ont d\u00e9lib\u00e9r\u00e9ment choisi de rendre leurs compilateurs peu intelligents pour \u00e9viter d’avoir \u00e0 faire tout cela. Pour le meilleur ou pour le pire, Kotlin a pris une autre voie, et il semble que les fonctionnalit\u00e9s qui rendent le compilateur Kotlin si intelligent soient celles qui sont le plus appr\u00e9ci\u00e9es des utilisateurs car elles fournissent \u00e0 la fois des abstractions puissantes et un code lisible et concis.<\/p>\n Alors que nous travaillons sur un compilateur front-end de nouvelle g\u00e9n\u00e9ration qui rendra la compilation beaucoup plus rapide en repensant l’impl\u00e9mentation des algorithmes de base de contr\u00f4le de type et de r\u00e9solution de noms, nous savons que tout ce qui est d\u00e9crit dans cet article ne dispara\u00eetra jamais. L’une des raisons \u00e0 cela est l’exp\u00e9rience avec le langage de programmation Java, qui b\u00e9n\u00e9ficie des capacit\u00e9s de compilation incr\u00e9mentale d’IntelliJ IDEA m\u00eame en ayant un compilateur beaucoup plus rapide que celui de kotlinc aujourd’hui. Une autre raison est que notre objectif est de nous rapprocher le plus possible du d\u00e9veloppement des cycles des langages interpr\u00e9t\u00e9s qui b\u00e9n\u00e9ficient d’une prise en charge instantan\u00e9e des modifications sans aucune compilation. Ainsi, la strat\u00e9gie de Kotlin pour une compilation rapide consiste en : un compilateur optimis\u00e9 + une cha\u00eene d’outils performante + une incr\u00e9mentalit\u00e9 sophistiqu\u00e9e. <\/p>\n Si vous aimez travailler sur ce genre de sujets, consultez l’offre d’emploi \u00e0 pourvoir actuellement au sein de l’\u00e9quipe JetBrains d\u00e9di\u00e9e \u00e0 la compilation rapide de Kotlin. Vous trouverez ici l’offre d’emploi en anglais<\/a> et en russe<\/a>. Une exp\u00e9rience pr\u00e9alable sur des compilateurs ou des outils de build n’est PAS requise. Nous recrutons dans tous les bureaux de JetBrains (Saint Petersbourg<\/a>, Munich<\/a>, Amsterdam<\/a>, Boston<\/a>, Prague<\/a>, Moscou<\/a> et Novossibirsk<\/a>) ou vous pouvez travailler \u00e0 distance<\/strong><\/a> partout dans le monde<\/strong>. N’h\u00e9sitez pas \u00e0 nous contacter\u00a0!<\/p>\nCommen\u00e7ons par l’incontournable bande dessin\u00e9e XKCD #303<\/a><\/strong><\/h3>\n
![\"Bande](\"https:\/\/imgs.xkcd.com\/comics\/compiling.png\")
<\/p>\n\n
Pourquoi la compilation prend-elle autant de temps\u00a0?<\/h3>\n
\n
La position de Kotlin<\/h3>\n
Un compilateur peut-il \u00eatre intelligent et rapide \u00e0 la fois\u00a0?<\/h3>\n
\n
\u00c9viter de compiler<\/h2>\n
\n
\n
Suivi les modifications de l’ABI<\/h3>\n
\n
\n
Avantages et inconv\u00e9nients de l’\u00e9vitement de compilation<\/h3>\n
La compilation incr\u00e9mentale<\/h2>\n
\n
\n
\n
Compiler les fichiers ayant \u00e9t\u00e9 modifi\u00e9s depuis la derni\u00e8re compilation (dirty files)<\/h3>\n
\n
\n
\n
\n
\u00c9tendre l’ensemble de fichiers modifi\u00e9s (dirty files)<\/h3>\n
foo<\/code> en bar<\/code>, il faut seulement recompiler les fichiers contenant les noms foo<\/code> et bar<\/code> et ne pas toucher aux autres fichiers, m\u00eame s’ils font r\u00e9f\u00e9rence \u00e0 d’autres parties de cette ABI. Le compilateur incr\u00e9mental se souvient des fichiers qui d\u00e9pendent de telle ou telle d\u00e9claration de la compilation pr\u00e9c\u00e9dente et nous pouvons utiliser ces donn\u00e9es un peu comme un graphique de d\u00e9pendance de module. L\u00e0 encore, il s’agit d’une op\u00e9ration que les compilateurs non incr\u00e9mentaux n’effectuent pas normalement.<\/p>\n\r\n\/\/ rename this to be 'fun foo(i: Int)'\r\nfun changeMe(i: Int) = if (i == 1) 0 else bar().length\r\n<\/pre>\n
\r\nfun foo(a: Any) = ""\r\nfun bar() = foo(1)\r\n<\/pre>\n
changeMe<\/code> en foo<\/code>. Notez que, bien que clean.kt ne soit pas modifi\u00e9, le corps de bar()<\/code> changera \u00e0 la recompilation : il appellera d\u00e9sormais foo(Int)<\/code> de dirty.kt, et non plus foo(Any)<\/code> de clean.kt, et son type de retour changera \u00e9galement. Il faut donc recompiler les fichiers dirty.kt et les fichiers clean.kt. Comment le compilateur incr\u00e9mental peut-il trouver cela ?<\/p>\n\n
changeMe<\/code>,<\/li>\nfoo<\/code> prend un Int<\/code> et renvoie un Int<\/code>.<\/li>\n<\/ul>\nfoo<\/code>. Cela signifie que nous devons recompiler les deux fichiers<\/strong> clean.kt et dirty.kt une nouvelle fois. Pourquoi\u00a0? Parce qu’on ne peut pas faire confiance aux types.<\/p>\nfoo<\/code> dans dirty.kt. Il est d\u00e9duit, et en r\u00e9alit\u00e9 d\u00e9pend du type de bar<\/code> de clean.kt qui est une d\u00e9pendance circulaire entre les fichiers. Le type de retour pourrait donc changer lorsque nous ajoutons clean.kt. Dans ce cas, nous obtiendrons une erreur de compilation, mais jusqu’\u00e0 ce que nous recompilions clean.kt avec dirty.kt<\/em>, nous n’en savons rien.<\/p>\n\n
La compilation incr\u00e9mentale au-del\u00e0 des limites des modules<\/h3>\n
Points non abord\u00e9s dans cet article<\/h2>\n
\n
En r\u00e9sum\u00e9<\/h2>\n
Rejoignez notre \u00e9quipe!<\/h2>\n