aboutsummaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/_templates/layout.html6
-rw-r--r--docs/abi-spec.rst3
-rw-r--r--docs/assembly.rst2
-rw-r--r--docs/conf.py4
-rw-r--r--docs/contracts.rst46
-rw-r--r--docs/contributing.rst4
-rw-r--r--docs/control-structures.rst99
-rw-r--r--docs/grammar.txt2
-rw-r--r--docs/index.rst2
-rw-r--r--docs/layout-of-source-files.rst2
-rw-r--r--docs/miscellaneous.rst9
-rw-r--r--docs/requirements.txt1
-rw-r--r--docs/types.rst27
-rw-r--r--docs/utils/SolidityLexer.py82
-rw-r--r--docs/yul.rst (renamed from docs/julia.rst)47
15 files changed, 105 insertions, 231 deletions
diff --git a/docs/_templates/layout.html b/docs/_templates/layout.html
new file mode 100644
index 00000000..1db4ef92
--- /dev/null
+++ b/docs/_templates/layout.html
@@ -0,0 +1,6 @@
+{% extends "!layout.html" %}
+
+ {% block menu %}
+ {{ super() }}
+ <a href="genindex.html">Keyword Index</a>
+ {% endblock %}
diff --git a/docs/abi-spec.rst b/docs/abi-spec.rst
index b0d63bb5..2fb207c7 100644
--- a/docs/abi-spec.rst
+++ b/docs/abi-spec.rst
@@ -72,8 +72,7 @@ The following non-fixed-size types exist:
- ``<type>[]``: a variable-length array of elements of the given type.
-Types can be combined to a tuple by enclosing a finite non-negative number
-of them inside parentheses, separated by commas:
+Types can be combined to a tuple by enclosing them inside parentheses, separated by commas:
- ``(T1,T2,...,Tn)``: tuple consisting of the types ``T1``, ..., ``Tn``, ``n >= 0``
diff --git a/docs/assembly.rst b/docs/assembly.rst
index f7b721ab..edc826ac 100644
--- a/docs/assembly.rst
+++ b/docs/assembly.rst
@@ -220,8 +220,6 @@ In the grammar, opcodes are represented as pre-defined identifiers.
+-------------------------+-----+---+-----------------------------------------------------------------+
| keccak256(p, n) | | F | keccak(mem[p...(p+n))) |
+-------------------------+-----+---+-----------------------------------------------------------------+
-| sha3(p, n) | | F | keccak(mem[p...(p+n))) |
-+-------------------------+-----+---+-----------------------------------------------------------------+
| jump(label) | `-` | F | jump to label / code position |
+-------------------------+-----+---+-----------------------------------------------------------------+
| jumpi(label, cond) | `-` | F | jump to label if cond is nonzero |
diff --git a/docs/conf.py b/docs/conf.py
index 7e107f2a..fdb67367 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -24,7 +24,7 @@ import re
def setup(sphinx):
thisdir = os.path.dirname(os.path.realpath(__file__))
sys.path.insert(0, thisdir + '/utils')
- from SolidityLexer import SolidityLexer
+ from pygments_lexer_solidity import SolidityLexer
sphinx.add_lexer('Solidity', SolidityLexer())
# -- General configuration ------------------------------------------------
@@ -112,7 +112,7 @@ highlight_language = 'Solidity'
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
-html_theme = 'default'
+html_theme = 'sphinx_rtd_theme'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
diff --git a/docs/contracts.rst b/docs/contracts.rst
index 00ef3fc6..5e7eab80 100644
--- a/docs/contracts.rst
+++ b/docs/contracts.rst
@@ -194,10 +194,10 @@ In the following example, ``D``, can call ``c.getData()`` to retrieve the value
contract C {
uint private data;
- function f(uint a) private returns(uint b) { return a + 1; }
+ function f(uint a) private pure returns(uint b) { return a + 1; }
function setData(uint a) public { data = a; }
- function getData() public returns(uint) { return data; }
- function compute(uint a, uint b) internal returns (uint) { return a+b; }
+ function getData() public view returns(uint) { return data; }
+ function compute(uint a, uint b) internal pure returns (uint) { return a + b; }
}
contract D {
@@ -526,9 +526,14 @@ In addition to the list of state modifying statements explained above, the follo
It is not possible to prevent functions from reading the state at the level
of the EVM, it is only possible to prevent them from writing to the state
(i.e. only ``view`` can be enforced at the EVM level, ``pure`` can not).
+ It is a non-circumventable runtime checks done by the EVM.
.. warning::
Before version 0.4.17 the compiler didn't enforce that ``pure`` is not reading the state.
+ It is a compile-time type check, which can be circumvented doing invalid explicit conversions
+ between contract types, because the compiler can verify that the type of the contract does
+ not do state-changing operations, but it cannot check that the contract that will be called
+ at runtime is actually of that type.
.. index:: ! fallback function, function;fallback
@@ -718,26 +723,22 @@ the contract can only see the last 256 block hashes.
Up to three parameters can
receive the attribute ``indexed`` which will cause the respective arguments
-to be searched for: It is possible to filter for specific values of
-indexed arguments in the user interface.
-
-If arrays (including ``string`` and ``bytes``) are used as indexed arguments, the
-Keccak-256 hash of it is stored as topic instead.
-
-The hash of the signature of the event is one of the topics except if you
+to be stored in a special data structure as so-called "topics", which allows them to be searched for,
+for example when filtering a sequence of blocks for certain events. Events can always
+be filtered by the address of the contract that emitted the event. Also,
+the hash of the signature of the event is one of the topics except if you
declared the event with ``anonymous`` specifier. This means that it is
not possible to filter for specific anonymous events by name.
-All non-indexed arguments will be stored in the data part of the log.
+If arrays (including ``string`` and ``bytes``) are used as indexed arguments, the
+Keccak-256 hash of it is stored as topic instead. This is because a topic
+can only hold a single word (32 bytes).
-.. note::
- Indexed arguments will not be stored themselves. You can only
- search for the values, but it is impossible to retrieve the
- values themselves.
+All non-indexed arguments will be :ref:`ABI-encoded <ABI>` into the data part of the log.
::
- pragma solidity ^0.4.0;
+ pragma solidity ^0.4.21;
contract ClientReceipt {
event Deposit(
@@ -769,7 +770,7 @@ The use in the JavaScript API would be as follows:
// watch for changes
event.watch(function(error, result){
// result will contain various information
- // including the argumets given to the `Deposit`
+ // including the arguments given to the `Deposit`
// call.
if (!error)
console.log(result);
@@ -1156,11 +1157,11 @@ Interfaces
Interfaces are similar to abstract contracts, but they cannot have any functions implemented. There are further restrictions:
-#. Cannot inherit other contracts or interfaces.
-#. Cannot define constructor.
-#. Cannot define variables.
-#. Cannot define structs.
-#. Cannot define enums.
+- Cannot inherit other contracts or interfaces.
+- Cannot define constructor.
+- Cannot define variables.
+- Cannot define structs.
+- Cannot define enums.
Some of these restrictions might be lifted in the future.
@@ -1322,6 +1323,7 @@ custom types without the overhead of external function calls:
if (carry > 0) {
// too bad, we have to add a limb
uint[] memory newLimbs = new uint[](r.limbs.length + 1);
+ uint i;
for (i = 0; i < r.limbs.length; ++i)
newLimbs[i] = r.limbs[i];
newLimbs[i] = carry;
diff --git a/docs/contributing.rst b/docs/contributing.rst
index 6717a8b9..eabf40b7 100644
--- a/docs/contributing.rst
+++ b/docs/contributing.rst
@@ -54,6 +54,8 @@ However, if you are making a larger change, please consult with the `Solidity De
<https://gitter.im/ethereum/solidity-dev>`_ (different from the one mentioned above, this on is
focused on compiler and language development instead of language use) first.
+New features and bugfixes should be added to the ``Changelog.md`` file: please
+follow the style of previous entries, when applicable.
Finally, please make sure you respect the `coding style
<https://raw.githubusercontent.com/ethereum/solidity/develop/CODING_STYLE.md>`_
@@ -111,7 +113,7 @@ Example: ``./test/libsolidity/syntaxTests/double_stateVariable_declaration.sol``
A syntax test must contain at least the contract under test itself, followed by the seperator ``----``. The additional comments above are used to describe the
expected compiler errors or warnings. This section can be empty in case that the contract should compile without any errors or warnings.
-In the above example, the state variable ``variable`` was declared twice, which is not allowed. This will result in a ``DeclarationError`` stating that the identifer was already declared.
+In the above example, the state variable ``variable`` was declared twice, which is not allowed. This will result in a ``DeclarationError`` stating that the identifier was already declared.
The tool that is being used for those tests is called ``isoltest`` and can be found under ``./test/tools/``. It is an interactive tool which allows
editing of failing contracts using your prefered text editor. Let's try to break this test by removing the second declaration of ``variable``:
diff --git a/docs/control-structures.rst b/docs/control-structures.rst
index 7849d15a..cc1f7ca5 100644
--- a/docs/control-structures.rst
+++ b/docs/control-structures.rst
@@ -325,74 +325,7 @@ is ``false``. The default value for the ``uint`` or ``int`` types is ``0``. For
element will be initialized to the default value corresponding to its type. Finally, for dynamically-sized arrays, ``bytes``
and ``string``, the default value is an empty array or string.
-A variable declared anywhere within a function will be in scope for the *entire function*, regardless of where it is declared
-(this will change soon, see below).
-This happens because Solidity inherits its scoping rules from JavaScript.
-This is in contrast to many languages where variables are only scoped where they are declared until the end of the semantic block.
-As a result, the following code is illegal and cause the compiler to throw an error, ``Identifier already declared``:
-
-::
-
- // This will not compile
-
- pragma solidity ^0.4.16;
-
- contract ScopingErrors {
- function scoping() public {
- uint i = 0;
-
- while (i++ < 1) {
- uint same1 = 0;
- }
-
- while (i++ < 2) {
- uint same1 = 0;// Illegal, second declaration of same1
- }
- }
-
- function minimalScoping() public {
- {
- uint same2 = 0;
- }
-
- {
- uint same2 = 0;// Illegal, second declaration of same2
- }
- }
-
- function forLoopScoping() public {
- for (uint same3 = 0; same3 < 1; same3++) {
- }
-
- for (uint same3 = 0; same3 < 1; same3++) {// Illegal, second declaration of same3
- }
- }
- }
-
-In addition to this, if a variable is declared, it will be initialized at the beginning of the function to its default value.
-As a result, the following code is legal, despite being poorly written:
-
-::
-
- pragma solidity ^0.4.0;
-
- contract C {
- function foo() public pure returns (uint) {
- // baz is implicitly initialized as 0
- uint bar = 5;
- if (true) {
- bar += baz;
- } else {
- uint baz = 10;// never executes
- }
- return bar;// returns 5
- }
- }
-
-Scoping starting from Version 0.5.0
------------------------------------
-
-Starting from version 0.5.0, Solidity will change to the more widespread scoping rules of C99
+Scoping in Solidity follows the widespread scoping rules of C99
(and many other languages): Variables are visible from the point right after their declaration
until the end of a ``{ }``-block. As an exception to this rule, variables declared in the
initialization part of a for-loop are only visible until the end of the for-loop.
@@ -401,17 +334,12 @@ Variables and other items declared outside of a code block, for example function
user-defined types, etc., do not change their scoping behaviour. This means you can
use state variables before they are declared and call functions recursively.
-These rules are already introduced now as an experimental feature.
-
As a consequence, the following examples will compile without warnings, since
-the two variables have the same name but disjoint scopes. In non-0.5.0-mode,
-they have the same scope (the function ``minimalScoping``) and thus it does
-not compile there.
+the two variables have the same name but disjoint scopes.
::
- pragma solidity ^0.4.0;
- pragma experimental "v0.5.0";
+ pragma solidity >0.4.24;
contract C {
function minimalScoping() pure public {
{
@@ -430,8 +358,7 @@ In any case, you will get a warning about the outer variable being shadowed.
::
- pragma solidity ^0.4.0;
- pragma experimental "v0.5.0";
+ pragma solidity >0.4.24;
contract C {
function f() pure public returns (uint) {
uint x = 1;
@@ -443,6 +370,24 @@ In any case, you will get a warning about the outer variable being shadowed.
}
}
+.. warning::
+ Before version 0.5.0 Solidity followed the same scoping rules as JavaScript, that is, a variable declared anywhere within a function would be in scope
+ for the entire function, regardless where it was declared. Note that this is a breaking change. The following example shows a code snippet that used
+ to compile but leads to an error starting from version 0.5.0.
+
+ ::
+
+ // This will not compile
+
+ pragma solidity >0.4.24;
+ contract C {
+ function f() pure public returns (uint) {
+ x = 2;
+ uint x;
+ return x;
+ }
+ }
+
.. index:: ! exception, ! throw, ! assert, ! require, ! revert
Error handling: Assert, Require, Revert and Exceptions
diff --git a/docs/grammar.txt b/docs/grammar.txt
index 0dda4f49..5d977827 100644
--- a/docs/grammar.txt
+++ b/docs/grammar.txt
@@ -57,7 +57,7 @@ Mapping = 'mapping' '(' ElementaryTypeName '=>' TypeName ')'
ArrayTypeName = TypeName '[' Expression? ']'
FunctionTypeName = 'function' FunctionTypeParameterList ( 'internal' | 'external' | StateMutability )*
( 'returns' FunctionTypeParameterList )?
-StorageLocation = 'memory' | 'storage'
+StorageLocation = 'memory' | 'storage' | 'calldata'
StateMutability = 'pure' | 'constant' | 'view' | 'payable'
Block = '{' Statement* '}'
diff --git a/docs/index.rst b/docs/index.rst
index 80b0d6e7..a57b93e4 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -169,7 +169,7 @@ Contents
using-the-compiler.rst
metadata.rst
abi-spec.rst
- julia.rst
+ yul.rst
style-guide.rst
common-patterns.rst
bugs.rst
diff --git a/docs/layout-of-source-files.rst b/docs/layout-of-source-files.rst
index f9d197b7..81faf816 100644
--- a/docs/layout-of-source-files.rst
+++ b/docs/layout-of-source-files.rst
@@ -198,7 +198,7 @@ for the two input parameters and two returned values.
pragma solidity ^0.4.0;
/** @title Shape calculator. */
- contract shapeCalculator {
+ contract ShapeCalculator {
/** @dev Calculates a rectangle's surface and perimeter.
* @param w Width of the rectangle.
* @param h Height of the rectangle.
diff --git a/docs/miscellaneous.rst b/docs/miscellaneous.rst
index c7c32528..108d4c96 100644
--- a/docs/miscellaneous.rst
+++ b/docs/miscellaneous.rst
@@ -190,7 +190,7 @@ important for static analysis tools that operate on bytecode level and
for displaying the current position in the source code inside a debugger
or for breakpoint handling.
-Both kinds of source mappings use integer indentifiers to refer to source files.
+Both kinds of source mappings use integer identifiers to refer to source files.
These are regular array indices into a list of source files usually called
``"sourceList"``, which is part of the combined-json and the output of
the json / npm compiler.
@@ -409,8 +409,11 @@ Reserved Keywords
These keywords are reserved in Solidity. They might become part of the syntax in the future:
-``abstract``, ``after``, ``case``, ``catch``, ``default``, ``final``, ``in``, ``inline``, ``let``, ``match``, ``null``,
-``of``, ``relocatable``, ``static``, ``switch``, ``try``, ``type``, ``typeof``.
+``abstract``, ``after``, ``alias``, ``apply``, ``auto``, ``case``, ``catch``, ``copyof``, ``default``,
+``define``, ``final``, ``immutable``, ``implements``, ``in``, ``inline``, ``let``, ``macro``, ``match``,
+``mutable``, ``null``, ``of``, ``override``, ``partial``, ``promise``, ``reference``, ``relocatable``,
+``sealed``, ``sizeof``, ``static``, ``supports``, ``switch``, ``try``, ``type``, ``typedef``, ``typeof``,
+``unchecked``.
Language Grammar
================
diff --git a/docs/requirements.txt b/docs/requirements.txt
index 0607b1ef..5fba631c 100644
--- a/docs/requirements.txt
+++ b/docs/requirements.txt
@@ -1 +1,2 @@
sphinx_rtd_theme>=0.3.1
+pygments-lexer-solidity>=0.3.1
diff --git a/docs/types.rst b/docs/types.rst
index 3f799c32..009896d5 100644
--- a/docs/types.rst
+++ b/docs/types.rst
@@ -60,15 +60,14 @@ operators are :ref:`literals<rational_literals>` (or literal expressions).
Division by zero and modulus with zero throws a runtime exception.
The result of a shift operation is the type of the left operand. The
-expression ``x << y`` is equivalent to ``x * 2**y``, and ``x >> y`` is
-equivalent to ``x / 2**y``. This means that shifting negative numbers
-sign extends. Shifting by a negative amount throws a runtime exception.
+expression ``x << y`` is equivalent to ``x * 2**y``, and, for positive integers,
+``x >> y`` is equivalent to ``x / 2**y``. For negative ``x``, ``x >> y``
+is equivalent to dividing by a power of ``2`` while rounding down (towards negative infinity).
+Shifting by a negative amount throws a runtime exception.
.. warning::
- The results produced by shift right of negative values of signed integer types is different from those produced
- by other programming languages. In Solidity, shift right maps to division so the shifted negative values
- are going to be rounded towards zero (truncated). In other programming languages the shift right of negative values
- works like division with rounding down (towards negative infinity).
+ Before version ``0.5.0`` a right shift ``x >> y`` for negative ``x`` was equivalent to ``x / 2**y``,
+ i.e. right shifts used rounding towards zero instead of rounding towards negative infinity.
.. index:: ! ufixed, ! fixed, ! fixed point number
@@ -226,10 +225,6 @@ Dynamically-sized byte array
``string``:
Dynamically-sized UTF-8-encoded string, see :ref:`arrays`. Not a value-type!
-As a rule of thumb, use ``bytes`` for arbitrary-length raw byte data and ``string``
-for arbitrary-length string (UTF-8) data. If you can limit the length to a certain
-number of bytes, always use one of ``bytes1`` to ``bytes32`` because they are much cheaper.
-
.. index:: address, literal;address
.. _address_literals:
@@ -602,8 +597,10 @@ shaves off one level in the type from the right).
Variables of type ``bytes`` and ``string`` are special arrays. A ``bytes`` is similar to ``byte[]``,
but it is packed tightly in calldata. ``string`` is equal to ``bytes`` but does not allow
length or index access (for now).
-
So ``bytes`` should always be preferred over ``byte[]`` because it is cheaper.
+As a rule of thumb, use ``bytes`` for arbitrary-length raw byte data and ``string``
+for arbitrary-length string (UTF-8) data. If you can limit the length to a certain
+number of bytes, always use one of ``bytes1`` to ``bytes32`` because they are much cheaper.
.. note::
If you want to access the byte-representation of a string ``s``, use
@@ -675,14 +672,14 @@ possible:
function f() public {
// The next line creates a type error because uint[3] memory
// cannot be converted to uint[] memory.
- uint[] x = [uint(1), 3, 4];
+ uint[] memory x = [uint(1), 3, 4];
}
}
It is planned to remove this restriction in the future but currently creates
some complications because of how arrays are passed in the ABI.
-.. index:: ! array;length, length, push, !array;push
+.. index:: ! array;length, length, push, pop, !array;push, !array;pop
Members
^^^^^^^
@@ -693,6 +690,8 @@ Members
``.length`` member. This does not happen automatically when attempting to access elements outside the current length. The size of memory arrays is fixed (but dynamic, i.e. it can depend on runtime parameters) once they are created.
**push**:
Dynamic storage arrays and ``bytes`` (not ``string``) have a member function called ``push`` that can be used to append an element at the end of the array. The function returns the new length.
+**pop**:
+ Dynamic storage arrays and ``bytes`` (not ``string``) have a member function called ``pop`` that can be used to remove an element from the end of the array.
.. warning::
It is not yet possible to use arrays of arrays in external functions.
diff --git a/docs/utils/SolidityLexer.py b/docs/utils/SolidityLexer.py
deleted file mode 100644
index 50f51cf4..00000000
--- a/docs/utils/SolidityLexer.py
+++ /dev/null
@@ -1,82 +0,0 @@
-# -*- coding: utf-8 -*-
-
-import re
-import copy
-
-from pygments.lexer import RegexLexer, ExtendedRegexLexer, bygroups, using, \
- include, this
-from pygments.token import Text, Comment, Operator, Keyword, Name, String, \
- Number, Other, Punctuation, Literal
-
-__all__ = ['SolidityLexer']
-
-class SolidityLexer(RegexLexer):
- name = "Solidity"
- aliases = ['sol', 'solidity']
- filenames = ['*.sol']
- mimetypes = []
- flags = re.DOTALL
- tokens = {
- 'commentsandwhitespace': [
- (r'\s+', Text),
- (r'<!--', Comment),
- (r'///', Comment.Special, 'docstringsingle'),
- (r'//.*?\n', Comment.Single),
- (r'/\*\*', Comment.Special, 'docstringmulti'),
- (r'/\*.*?\*/', Comment.Multiline)
- ],
- 'natspec': [
- (r'@author|@dev|@notice|@return|@param|@title', Keyword),
- (r'.[^@*\n]*?', Comment.Special)
- ],
- 'docstringsingle': [
- (r'\n', Comment.Special, '#pop'),
- include('natspec')
- ],
- 'docstringmulti': [
- (r'\*/', Comment.Special, '#pop'),
- include('natspec')
- ],
- 'slashstartsregex': [
- include('commentsandwhitespace'),
- (r'/(\\.|[^[/\\\n]|\[(\\.|[^\]\\\n])*])+/'
- r'([gim]+\b|\B)', String.Regex, '#pop'),
- (r'(?=/)', Text, ('#pop', 'badregex')),
- (r'', Text, '#pop')
- ],
- 'badregex': [
- (r'\n', Text, '#pop')
- ],
- 'root': [
- (r'^(?=\s|/|<!--)', Text, 'slashstartsregex'),
- include('commentsandwhitespace'),
- (r'\+\+|--|\*\*|~|&&|\?|:|\|\||\\(?=\n)|'
- r'(<<|>>>?|==?|!=?|[-<>+*%&\|\^/])=?', Operator, 'slashstartsregex'),
- (r'[{(\[;,]', Punctuation, 'slashstartsregex'),
- (r'[})\].]', Punctuation),
- (r'(anonymous|as|assembly|break|constant|continue|do|delete|else|external|for|hex|if|'
- r'indexed|internal|import|is|mapping|memory|new|payable|public|pragma|'
- r'private|pure|return|returns|storage|super|this|throw|using|view|while)\b', Keyword, 'slashstartsregex'),
- (r'(var|function|event|modifier|struct|enum|contract|library|interface)\b', Keyword.Declaration, 'slashstartsregex'),
- (r'(bytes|string|address|uint|int|bool|byte|' +
- '|'.join(
- ['uint%d' % (i + 8) for i in range(0, 256, 8)] +
- ['int%d' % (i + 8) for i in range(0, 256, 8)] +
- ['bytes%d' % (i + 1) for i in range(0, 32)] +
- ['ufixed%dx%d' % ((i), (j + 8)) for i in range(0, 256, 8) for j in range(0, 256 - i, 8)] +
- ['fixed%dx%d' % ((i), (j + 8)) for i in range(0, 256, 8) for j in range(0, 256 - i, 8)]
- ) + r')\b', Keyword.Type, 'slashstartsregex'),
- (r'(wei|szabo|finney|ether|seconds|minutes|hours|days|weeks|years)\b', Keyword.Type, 'slashstartsregex'),
- (r'(abstract|after|case|catch|default|final|in|inline|let|match|'
- r'null|of|relocatable|static|switch|try|type|typeof)\b', Keyword.Reserved),
- (r'(true|false)\b', Keyword.Constant),
- (r'(block|msg|tx|now|suicide|selfdestruct|addmod|mulmod|sha3|keccak256|log[0-4]|'
- r'sha256|ecrecover|ripemd160|assert|revert|require)', Name.Builtin),
- (r'[$a-zA-Z_][a-zA-Z0-9_]*', Name.Other),
- (r'[0-9][0-9]*\.[0-9]+([eE][0-9]+)?', Number.Float),
- (r'0x[0-9a-fA-F]+', Number.Hex),
- (r'[0-9]+([eE][0-9]+)?', Number.Integer),
- (r'"(\\\\|\\"|[^"])*"', String.Double),
- (r"'(\\\\|\\'|[^'])*'", String.Single),
- ]
- }
diff --git a/docs/julia.rst b/docs/yul.rst
index c9b73db2..4f5ef98f 100644
--- a/docs/julia.rst
+++ b/docs/yul.rst
@@ -1,18 +1,19 @@
-#################################################
-Joyfully Universal Language for (Inline) Assembly
-#################################################
+###
+Yul
+###
-.. _julia:
+.. _yul:
-.. index:: ! assembly, ! asm, ! evmasm, ! julia
+.. index:: ! assembly, ! asm, ! evmasm, ! yul, julia, iulia
-JULIA is an intermediate language that can compile to various different backends
+Yul (previously also called JULIA or IULIA) is an intermediate language that can
+compile to various different backends
(EVM 1.0, EVM 1.5 and eWASM are planned).
Because of that, it is designed to be a usable common denominator of all three
platforms.
It can already be used for "inline assembly" inside Solidity and
-future versions of the Solidity compiler will even use JULIA as intermediate
-language. It should also be easy to build high-level optimizer stages for JULIA.
+future versions of the Solidity compiler will even use Yul as intermediate
+language. It should also be easy to build high-level optimizer stages for Yul.
.. note::
@@ -21,14 +22,14 @@ language. It should also be easy to build high-level optimizer stages for JULIA.
to the EVM opcodes. Please resort to the inline assembly documentation
for details.
-The core components of JULIA are functions, blocks, variables, literals,
+The core components of Yul are functions, blocks, variables, literals,
for-loops, if-statements, switch-statements, expressions and assignments to variables.
-JULIA is typed, both variables and literals must specify the type with postfix
+Yul is typed, both variables and literals must specify the type with postfix
notation. The supported types are ``bool``, ``u8``, ``s8``, ``u32``, ``s32``,
``u64``, ``s64``, ``u128``, ``s128``, ``u256`` and ``s256``.
-JULIA in itself does not even provide operators. If the EVM is targeted,
+Yul in itself does not even provide operators. If the EVM is targeted,
opcodes will be available as built-in functions, but they can be reimplemented
if the backend changes. For a list of mandatory built-in functions, see the section below.
@@ -69,10 +70,10 @@ and ``add`` to be available.
}
}
-Specification of JULIA
-======================
+Specification of Yul
+====================
-JULIA code is described in this chapter. JULIA code is usually placed into a JULIA object, which is described in the following chapter.
+This chapter describes Yul code. It is usually placed inside a Yul object, which is described in the following chapter.
Grammar::
@@ -156,7 +157,7 @@ Literals cannot be larger than the their type. The largest type defined is 256-b
Scoping Rules
-------------
-Scopes in JULIA are tied to Blocks (exceptions are functions and the for loop
+Scopes in Yul are tied to Blocks (exceptions are functions and the for loop
as explained below) and all declarations
(``FunctionDefinition``, ``VariableDeclaration``)
introduce new identifiers into these scopes.
@@ -186,7 +187,7 @@ outside of that function.
Formal Specification
--------------------
-We formally specify JULIA by providing an evaluation function E overloaded
+We formally specify Yul by providing an evaluation function E overloaded
on the various nodes of the AST. Any functions can have side effects, so
E takes two state objects and the AST node and returns two new
state objects and a variable number of other values.
@@ -303,7 +304,7 @@ We will use a destructuring notation for the AST nodes.
Type Conversion Functions
-------------------------
-JULIA has no support for implicit type conversion and therefore functions exists to provide explicit conversion.
+Yul has no support for implicit type conversion and therefore functions exist to provide explicit conversion.
When converting a larger type to a shorter type a runtime exception can occur in case of an overflow.
Truncating conversions are supported between the following types:
@@ -507,7 +508,7 @@ The following functions must be available:
Backends
--------
-Backends or targets are the translators from JULIA to a specific bytecode. Each of the backends can expose functions
+Backends or targets are the translators from Yul to a specific bytecode. Each of the backends can expose functions
prefixed with the name of the backend. We reserve ``evm_`` and ``ewasm_`` prefixes for the two proposed backends.
Backend: EVM
@@ -525,8 +526,8 @@ Backend: eWASM
TBD
-Specification of JULIA Object
-=============================
+Specification of Yul Object
+===========================
Grammar::
@@ -537,11 +538,11 @@ Grammar::
HexLiteral = 'hex' ('"' ([0-9a-fA-F]{2})* '"' | '\'' ([0-9a-fA-F]{2})* '\'')
StringLiteral = '"' ([^"\r\n\\] | '\\' .)* '"'
-Above, ``Block`` refers to ``Block`` in the JULIA code grammar explained in the previous chapter.
+Above, ``Block`` refers to ``Block`` in the Yul code grammar explained in the previous chapter.
-An example JULIA Object is shown below:
+An example Yul Object is shown below:
-..code::
+.. code::
// Code consists of a single object. A single "code" node is the code of the object.
// Every (other) named object or data section is serialized and
generated by cgit (git 2.34.1) at 2024-11-17 23:01:00 +0800