Skip to content

Commit

Permalink
Merge pull request #1 from solidity-docs/develop
Browse files Browse the repository at this point in the history
first commit
  • Loading branch information
stratusceo authored Feb 4, 2022
2 parents c6e044b + 42b7772 commit 11f3f1c
Show file tree
Hide file tree
Showing 86 changed files with 26,658 additions and 0 deletions.
1 change: 1 addition & 0 deletions .gitattributes
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
*.sol linguist-language=Solidity
85 changes: 85 additions & 0 deletions .gitignore
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
675 changes: 675 additions & 0 deletions LICENSE.txt

Large diffs are not rendered by default.

525 changes: 525 additions & 0 deletions docs/050-breaking-changes.rst

Large diffs are not rendered by default.

176 changes: 176 additions & 0 deletions docs/060-breaking-changes.rst
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.
133 changes: 133 additions & 0 deletions docs/070-breaking-changes.rst
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.
Loading

0 comments on commit 11f3f1c

Please sign in to comment.