-
Notifications
You must be signed in to change notification settings - Fork 7
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #1 from solidity-docs/develop
first commit
- Loading branch information
Showing
86 changed files
with
26,658 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
*.sol linguist-language=Solidity |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,85 @@ | ||
commit_hash.txt | ||
prerelease.txt | ||
|
||
# Compiled Object files | ||
*.slo | ||
*.lo | ||
*.o | ||
*.obj | ||
|
||
# Precompiled Headers | ||
*.gch | ||
*.pch | ||
|
||
# Compiled Dynamic libraries | ||
*.so | ||
*.dylib | ||
*.dll | ||
|
||
# Fortran module files | ||
*.mod | ||
|
||
# Compiled Static libraries | ||
*.lai | ||
*.la | ||
*.a | ||
*.lib | ||
|
||
# Executables | ||
*.exe | ||
*.out | ||
*.app | ||
|
||
# Build directory | ||
/build* | ||
emscripten_build/ | ||
docs/_build | ||
docs/_static/robots.txt | ||
__pycache__ | ||
docs/utils/*.pyc | ||
/deps/downloads/ | ||
deps/install | ||
deps/cache | ||
cmake-build-*/ | ||
|
||
# vim stuff | ||
[._]*.sw[a-p] | ||
[._]sw[a-p] | ||
|
||
# emacs stuff | ||
*~ | ||
|
||
# IDE files | ||
.idea | ||
.vscode | ||
browse.VC.db | ||
CMakeLists.txt.user | ||
/CMakeSettings.json | ||
/.vs | ||
/.cproject | ||
/.project | ||
|
||
# place to put local temporary files | ||
tmp | ||
|
||
|
||
.circleci | ||
cmake/ | ||
libevmasm/ | ||
liblangutil/ | ||
libsmtutil/ | ||
libsolc/ | ||
libsolidity/ | ||
libsolutil/ | ||
libyul/ | ||
scripts/ | ||
snap/ | ||
solc/ | ||
test/ | ||
tools/ | ||
.clang-format | ||
.dockerignore | ||
.editorconfig | ||
|
||
CMakeLists.txt | ||
CODE_OF_CONDUCT.md |
Large diffs are not rendered by default.
Oops, something went wrong.
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,176 @@ | ||
******************************** | ||
Solidity v0.6.0 Changements de rupture | ||
******************************** | ||
|
||
Cette section met en évidence les principaux changements de rupture introduits dans Solidity | ||
version 0.6.0, ainsi que le raisonnement derrière ces changements et la façon de mettre à jour | ||
code affecté. | ||
Pour la liste complète, consultez | ||
`le changelog de la version <https://github.com/ethereum/solidity/releases/tag/v0.6.0>`_. | ||
|
||
|
||
Changements dont le compilateur pourrait ne pas être averti | ||
========================================= | ||
|
||
Cette section liste les changements pour lesquels le comportement de votre code pourrait | ||
changer sans que le compilateur vous en avertisse. | ||
|
||
* Le type résultant d'une exponentiation est le type de la base. Il s'agissait auparavant du plus petit type | ||
qui peut contenir à la fois le type de la base et le type de l'exposant, comme pour les opérations symétriques. | ||
symétriques. De plus, les types signés sont autorisés pour la base de l'exponentiation. | ||
|
||
|
||
Exigences d'explicitation | ||
========================= | ||
|
||
Cette section liste les changements pour lesquels le code doit être plus explicite, | ||
mais la sémantique ne change pas. | ||
Pour la plupart des sujets, le compilateur fournira des suggestions. | ||
|
||
* Les fonctions ne peuvent maintenant être surchargées que lorsqu'elles sont marquées avec la clef | ||
``virtual`` ou définies dans une interface. Les fonctions sans | ||
Les fonctions sans implémentation en dehors d'une interface doivent être marquées ``virtual``. | ||
Lorsqu'on surcharge une fonction ou un modificateur, le nouveau mot-clé ``override`` doit être utilisé. | ||
doit être utilisé. Lorsqu'on remplace une fonction ou un modificateur défini dans plusieurs bases parallèles | ||
bases parallèles, toutes les bases doivent être listées entre parenthèses après le mot-clé | ||
comme ceci : ``override(Base1, Base2)``. | ||
|
||
* L'accès des membres à ``length`` des tableaux est maintenant toujours en lecture seule, même pour les tableaux de stockage. Il n'est plus possible de | ||
plus possible de redimensionner des tableaux de stockage en assignant une nouvelle valeur à leur longueur. Utilisez ``push()``, | ||
``push(value)`` ou ``pop()`` à la place, ou assignez un tableau complet, qui écrasera bien sûr le contenu existant. | ||
La raison derrière cela est d'éviter les collisions de stockage de gigantesques | ||
de stockage gigantesques. | ||
|
||
* Le nouveau mot-clé ``abstract`` peut être utilisé pour marquer les contrats comme étant abstraits. Il doit être utilisé | ||
si un contrat n'implémente pas toutes ses fonctions. Les contrats abstraits ne peuvent pas être créés en utilisant l'opérateur ``new``, | ||
et il n'est pas possible de générer du bytecode pour eux pendant la compilation. | ||
|
||
* Les bibliothèques doivent implémenter toutes leurs fonctions, pas seulement les fonctions internes. | ||
|
||
* Les noms des variables déclarées en inline assembly ne peuvent plus se terminer par ``_slot`` ou ``_offset``. | ||
|
||
* Les déclarations de variables dans l'assemblage en ligne ne peuvent plus suivre une déclaration en dehors du bloc d'assemblage en ligne. | ||
Si le nom contient un point, son préfixe jusqu'au point ne doit pas entrer en conflit avec une déclaration en dehors du bloc d'assemblage en ligne. | ||
d'assemblage. | ||
|
||
* Le shadowing de variables d'état est désormais interdit. Un contrat dérivé peut seulement | ||
déclarer une variable d'état ``x``, que s'il n'y a pas de variable d'état visible avec le même nom | ||
d'état visible portant le même nom dans l'une de ses bases. | ||
|
||
|
||
Changements sémantiques et syntaxiques | ||
============================== | ||
|
||
Cette section liste les changements pour lesquels vous devez modifier votre code | ||
et il fait quelque chose d'autre après. | ||
|
||
* Les conversions de types de fonctions externes en ``adresse`` sont maintenant interdites. A la place, les types de fonctions externes | ||
Au lieu de cela, les types de fonctions externes ont un membre appelé ``address``, similaire au membre ``selector`` existant. | ||
|
||
* La fonction ``push(value)`` pour les tableaux de stockage dynamique ne retourne plus la nouvelle longueur (elle ne retourne rien). | ||
|
||
* La fonction sans nom communément appelée "fonction de repli" a été divisée en une nouvelle fonction de repli définie à l'aide de la fonction de repli. | ||
nouvelle fonction de repli définie à l'aide du mot-clé ``fallback`` et une fonction de réception d'éther | ||
définie à l'aide du mot-clé ``receive``. | ||
|
||
* Si elle est présente, la fonction de réception de l'éther est appelée chaque fois que les données d'appel sont vides (que l'éther soit reçu ou non). | ||
(que l'éther soit reçu ou non). Cette fonction est implicitement ``payable``. | ||
|
||
* La nouvelle fonction de repli est appelée lorsqu'aucune autre fonction ne correspond (si la fonction receive ether | ||
n'existe pas, cela inclut les appels avec des données d'appel vides). | ||
Vous pouvez rendre cette fonction ``payable`` ou non. Si elle n'est pas "payante", alors les transactions | ||
ne correspondant à aucune autre fonction qui envoie une valeur seront inversées. Vous n'aurez besoin d'implémenter | ||
implémenter la nouvelle fonction de repli que si vous suivez un modèle de mise à niveau ou de proxy. | ||
|
||
|
||
Nouvelles fonctionnalités | ||
============ | ||
|
||
Cette section énumère des choses qui n'étaient pas possibles avant la version 0.6.0 de Solidity | ||
ou qui étaient plus difficiles à réaliser. | ||
|
||
* L'instruction :ref:`try/catch <try-catch>` vous permet de réagir à l'échec d'appels externes. | ||
* Les types ``struct`` et ``enum`` peuvent être déclarés au niveau du fichier. | ||
* Les tranches de tableau peuvent être utilisées pour les tableaux de données d'appel, par exemple "abi.decode(msg.data[4 :], (uint, uint))``. | ||
est un moyen de bas niveau pour décoder les données utiles de l'appel de fonction. | ||
* Natspec prend en charge les paramètres de retour multiples dans la documentation du développeur, en appliquant le même contrôle de nommage que ``@param``. | ||
* Yul et Inline Assembly ont une nouvelle instruction appelée ``leave`` qui quitte la fonction courante. | ||
* Les conversions de ``adresse`` en ``adresse payable`` sont maintenant possibles via ``payable(x)``, où | ||
``x`` doit être de type ``adresse``. | ||
|
||
|
||
Changements d'interface | ||
================= | ||
|
||
Cette section liste les changements qui ne sont pas liés au langage lui-même, mais qui ont un effet sur les interfaces du compilateur. | ||
le compilateur. Ces modifications peuvent changer la façon dont vous utilisez le compilateur sur la ligne de commande, la façon dont vous utilisez son interface programmable, ou la façon dont vous analysez la sortie qu'il produit. | ||
ou comment vous analysez la sortie qu'il produit. | ||
|
||
Nouveau rapporteur d'erreurs | ||
~~~~~~~~~~~~~~~~~~ | ||
|
||
Un nouveau rapporteur d'erreur a été introduit, qui vise à produire des messages d'erreur plus accessibles sur la ligne de commande. | ||
Il est activé par défaut, mais si vous passez ``--old-reporter``, vous revenez à l'ancien rapporteur d'erreurs, qui est déprécié. | ||
|
||
Options de hachage des métadonnées | ||
~~~~~~~~~~~~~~~~~~~~~ | ||
|
||
Le compilateur ajoute maintenant le hash `IPFS <https://ipfs.io/>`_ du fichier de métadonnées à la fin du bytecode par défaut. | ||
(pour plus de détails, voir la documentation sur :doc:`contract metadata <metadata>`). Avant la version 0.6.0, le compilateur ajoutait la balise | ||
`Swarm <https://ethersphere.github.io/swarm-home/>`_ hash par défaut, et afin de toujours supporter ce comportement, | ||
la nouvelle option de ligne de commande ``--metadata-hash`` a été introduite. Elle permet de sélectionner le hachage à produire et à ajouter | ||
ajouté, en passant soit ``ipfs`` soit ``swarm`` comme valeur à l'option de ligne de commande ``--metadata-hash``. | ||
Passer la valeur ``none`` supprime complètement le hachage. | ||
|
||
Ces changements peuvent également être utilisés via l'interface :ref:`Standard JSON Interface<compiler-api>` et affecter les métadonnées JSON générées par le compilateur. | ||
|
||
La façon recommandée de lire les métadonnées est de lire les deux derniers octets pour déterminer la longueur de l'encodage CBOR | ||
et d'effectuer un décodage correct sur ce bloc de données, comme expliqué dans la section :ref:`metadata<encoding-of-the-metadata-hash-in-the-bytecode>`. | ||
|
||
Optimiseur de Yul | ||
~~~~~~~~~~~~~ | ||
|
||
Avec l'optimiseur de bytecode hérité, l'optimiseur :doc:`Yul <yul>` est maintenant activé par défaut lorsque vous appelez le compilateur avec `--optimize`. | ||
avec ``--optimize``. Il peut être désactivé en appelant le compilateur avec `--no-optimize-yul``. | ||
Ceci affecte principalement le code qui utilise ABI coder v2. | ||
|
||
Modifications de l'API C | ||
~~~~~~~~~~~~~ | ||
|
||
Le code client qui utilise l'API C de ``libsolc`` a maintenant le contrôle de la mémoire utilisée par le compilateur. Pour rendre | ||
Pour rendre ce changement cohérent, ``solidity_free`` a été renommé en ``solidity_reset``, les fonctions ``solidity_alloc`` et ``solidity_free`` ont été modifiées. | ||
``solidity_free`` ont été ajoutées et ``solidity_compile`` retourne maintenant une chaîne de caractères qui doit être explicitement libérée par la fonction | ||
``solidity_free()``. | ||
|
||
|
||
Comment mettre à jour votre code | ||
======================= | ||
|
||
Cette section donne des instructions détaillées sur la façon de mettre à jour le code antérieur pour chaque changement de rupture. | ||
|
||
* Changez ``address(f)`` en ``f.address`` pour que ``f`` soit de type fonction externe. | ||
|
||
* Remplacer ``fonction () externe [payable] { ... }`` par soit ``receive() externe [payable] { ... }``, | ||
``fallback() externe [payable] { ... }` ou les deux. }`` ou les deux. Préférez | ||
l'utilisation d'une fonction ``receive`` uniquement, lorsque cela est possible. | ||
|
||
* Remplacez ``uint length = array.push(value)`` par ``array.push(value);``. La nouvelle longueur peut être | ||
accessible via ``array.length``. | ||
|
||
* Changez ``array.length++`` en ``array.push()`` pour augmenter, et utilisez ``pop()`` pour diminuer | ||
la longueur d'un tableau de stockage. | ||
|
||
* Pour chaque paramètre de retour nommé dans la documentation ``@dev`` d'une fonction, définissez une entrée ``@return`` contenant le nom du paramètre. | ||
qui contient le nom du paramètre comme premier mot. Par exemple, si vous avez une fonction "f()`` définie comme suit | ||
comme "fonction f() public returns (uint value)`` et une annotation `@dev``, documentez ses paramètres de retour comme suit | ||
de retour comme suit : ``@return value La valeur de retour.``. Vous pouvez mélanger des paramètres de retour nommés et non nommés | ||
documentation tant que les annotations sont dans l'ordre où elles apparaissent dans le type de retour du tuple. | ||
|
||
* Choisissez des identifiants uniques pour les déclarations de variables dans l'assemblage en ligne qui n'entrent pas en conflit avec les déclarations en dehors de l'assemblage en ligne. | ||
avec des déclarations en dehors du bloc d'assemblage en ligne. | ||
|
||
* Ajoutez "virtual" à chaque fonction non interface que vous avez l'intention de remplacer. Ajoutez ``virtual`` à toutes les fonctions sans implémentation en dehors des interfaces. | ||
à toutes les fonctions sans implémentation en dehors des interfaces. Pour l'héritage simple, ajoutez | ||
``override`` à chaque fonction de remplacement. Pour l'héritage multiple, ajoutez ``override(A, B, ..)``, | ||
où vous listez entre parenthèses tous les contrats qui définissent la fonction surchargée. Lorsque | ||
plusieurs bases définissent la même fonction, le contrat qui hérite doit remplacer toutes les fonctions conflictuelles. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,133 @@ | ||
******************************** | ||
Solidity v0.7.0 Changements de dernière minute | ||
******************************** | ||
|
||
Cette section met en évidence les principaux changements de rupture introduits dans Solidity | ||
version 0.7.0, ainsi que le raisonnement derrière ces changements et la façon de mettre à jour | ||
code affecté. | ||
Pour la liste complète, consultez | ||
le changelog de la version <https://github.com/ethereum/solidity/releases/tag/v0.7.0>`_. | ||
|
||
|
||
Changements silencieux de la sémantique | ||
=============================== | ||
|
||
* L'exponentiation et les décalages de littéraux par des non-littéraux (par exemple, ``1 << x`` ou ``2 ** x``) | ||
utiliseront toujours soit le type ``uint256`` (pour les littéraux non négatifs), soit le type | ||
``int256`` (pour les littéraux négatifs) pour effectuer l'opération. | ||
Auparavant, l'opération était effectuée dans le type de la quantité de décalage / l'exposant, ce qui peut être trompeur. | ||
exposant, ce qui peut être trompeur. | ||
|
||
|
||
Modifications de la syntaxe | ||
===================== | ||
|
||
* Dans les appels de fonctions externes et de création de contrats, l'éther et le gaz sont maintenant spécifiés en utilisant une nouvelle syntaxe : | ||
``x.f{gaz : 10000, valeur : 2 éther}(arg1, arg2)``. | ||
L'ancienne syntaxe -- ``x.f.gas(10000).value(2 ether)(arg1, arg2)`` -- provoquera une erreur. | ||
|
||
* La variable globale ``now`` est obsolète, ``block.timestamp`` devrait être utilisée à la place. | ||
L'identifiant unique ``now`` est trop générique pour une variable globale et pourrait donner l'impression | ||
qu'elle change pendant le traitement de la transaction, alors que ``block.timestamp`` reflète correctement | ||
reflète correctement le fait qu'il s'agit d'une propriété du bloc. | ||
|
||
* Les commentaires NatSpec sur les variables ne sont autorisés que pour les variables d'état publiques et non | ||
pour les variables locales ou internes. | ||
|
||
* Le jeton ``gwei`` est maintenant un mot-clé (utilisé pour spécifier, par exemple, ``2 gwei`` comme un nombre) | ||
et ne peut pas être utilisé comme un identifiant. | ||
|
||
* Les chaînes de caractères ne peuvent plus contenir que des caractères ASCII imprimables, ce qui inclut une variété de séquences d'échappement, telles que les hexadécimales. | ||
séquences d'échappement, telles que les échappements hexadécimaux (``xff``) et unicode (``u20ac``). | ||
|
||
* Les chaînes littérales Unicode sont désormais prises en charge pour accueillir les séquences UTF-8 valides. Ils sont identifiés | ||
avec le préfixe ``unicode`` : ``unicode "Hello 😃"``. | ||
|
||
* Mutabilité d'état : La mutabilité d'état des fonctions peut maintenant être restreinte pendant l'héritage : | ||
Les fonctions avec une mutabilité d'état par défaut peuvent être remplacées par des fonctions ``pure'' et ``view''. | ||
tandis que les fonctions ``view`` peuvent être remplacées par des fonctions ``pure``. | ||
En même temps, les variables d'état publiques sont considérées comme ``view`` et même ``pure`` si elles sont constantes. | ||
si elles sont des constantes. | ||
|
||
|
||
|
||
Assemblage en ligne | ||
--------------- | ||
|
||
* Interdire ``.`` dans les noms de fonctions et de variables définies par l'utilisateur dans l'assemblage en ligne. | ||
C'est toujours valable si vous utilisez Solidity en mode Yul-only. | ||
|
||
* L'emplacement et le décalage de la variable pointeur de stockage ``x`` sont accessibles via ``x.slot`` et ``x.offset``. | ||
et ``x.offset`` au lieu de ``x_slot`` et ``x_offset``. | ||
|
||
Suppression des fonctionnalités inutilisées ou dangereuses | ||
==================================== | ||
|
||
Mappages en dehors du stockage | ||
------------------------ | ||
|
||
* Si une structure ou un tableau contient un mappage, il ne peut être utilisé que dans le stockage. | ||
Auparavant, les membres du mappage étaient ignorés en mémoire, ce qui est déroutant et source d'erreurs. | ||
ce qui est déroutant et source d'erreurs. | ||
|
||
* Les affectations aux structures ou tableaux dans le stockage ne fonctionnent pas s'ils contiennent des mappings. | ||
mappings. | ||
Auparavant, les mappings étaient ignorés silencieusement pendant l'opération de copie, ce qui | ||
ce qui est trompeur et source d'erreurs. | ||
|
||
Fonctions et événements | ||
-------------------- | ||
|
||
* La visibilité (``public`` / ``internal`') n'est plus nécessaire pour les constructeurs : | ||
Pour empêcher un contrat d'être créé, il peut être marqué ``abstract``. | ||
Cela rend le concept de visibilité pour les constructeurs obsolète. | ||
|
||
* Contrôleur de type : Désaccorder ``virtual`` pour les fonctions de bibliothèque : | ||
Puisque les bibliothèques ne peuvent pas être héritées, les fonctions de bibliothèque ne devraient pas être virtuelles. | ||
|
||
* Plusieurs événements avec le même nom et les mêmes types de paramètres dans la même hiérarchie d'héritage sont interdits. | ||
même hiérarchie d'héritage sont interdits. | ||
|
||
* ``utiliser A pour B`` n'affecte que le contrat dans lequel il est mentionné. | ||
Auparavant, l'effet était hérité. Maintenant, vous devez répéter l'instruction "using" dans tous les contrats dérivés qui font usage de cette instruction. | ||
dans tous les contrats dérivés qui utilisent cette fonctionnalité. | ||
|
||
Expressions | ||
----------- | ||
|
||
* Les décalages par des types signés ne sont pas autorisés. | ||
Auparavant, les décalages par des montants négatifs étaient autorisés, mais ils étaient annulés à l'exécution. | ||
|
||
* Les dénominations ``finney`` et ``szabo`' sont supprimées. | ||
Elles sont rarement utilisées et ne rendent pas le montant réel facilement visible. A la place, des valeurs explicites | ||
valeurs explicites comme "1e20" ou le très commun "gwei" peuvent être utilisées. | ||
Déclarations | ||
------------ | ||
* Le mot-clé ``var`` ne peut plus être utilisé. | ||
Auparavant, ce mot-clé était analysé mais donnait lieu à une erreur de type et à une suggestion sur le type à utiliser. | ||
une suggestion sur le type à utiliser. Maintenant, il résulte en une erreur d'analyse. | ||
|
||
Changements d'interface | ||
================= | ||
|
||
* JSON AST : Marquer les littéraux de chaînes hexagonales avec ``kind : "hexString"``. | ||
* JSON AST : Les membres avec la valeur ``null`` sont supprimés de la sortie JSON. | ||
* NatSpec : Les constructeurs et les fonctions ont une sortie userdoc cohérente. | ||
|
||
|
||
Comment mettre à jour votre code | ||
======================= | ||
|
||
Cette section donne des instructions détaillées sur la façon de mettre à jour le code antérieur pour chaque changement de rupture. | ||
|
||
* Changez ``x.f.value(...)()`` en ``x.f{value : ...}()``. De même, ``(new C).value(...)()`` en | ||
``nouveau C{valeur : ...}()`` et ``x.f.gas(...).valeur(...)()`` en ``x.f{gas : ..., valeur : ...}()``. | ||
* Remplacez ``now`` par ``block.timestamp``. | ||
* Changez les types de l'opérande droit dans les opérateurs de décalage en types non signés. Par exemple, remplacez ``x >> (256 - y)`` par | ||
``x >> uint(256 - y)``. | ||
* Répétez les déclarations ``utilisant A pour B`` dans tous les contrats dérivés si nécessaire. | ||
* Supprimez le mot-clé "public" de chaque constructeur. | ||
* Supprimer le mot-clé "interne" de chaque constructeur et ajouter "abstrait" au contrat (s'il n'est pas déjà présent). | ||
* Changez les suffixes ``_slot`` et ``_offset`' dans l'assemblage en ligne en ``.slot`` et ``.offset`', respectivement. |
Oops, something went wrong.