solidity-docs · r0qs · Jul 21, 2022 · Jul 26, 2022 · Aug 3, 2022 · Aug 8, 2022
diff --git a/CMakeLists.txt b/CMakeLists.txt
@@ -21,7 +21,11 @@ include(EthPolicy)
 eth_policy()
 
 # project name and version should be set after cmake_policy CMP0048
+<<<<<<< HEAD
 set(PROJECT_VERSION "0.8.15")
+=======
+set(PROJECT_VERSION "0.8.17")
+>>>>>>> v0.8.17
 # OSX target needed in order to support std::visit
 set(CMAKE_OSX_DEPLOYMENT_TARGET "10.14")
 project(solidity VERSION ${PROJECT_VERSION} LANGUAGES C CXX)
@@ -35,6 +39,7 @@ endif()
 option(SOLC_LINK_STATIC "Link solc executable statically on supported platforms" OFF)
 option(SOLC_STATIC_STDLIBS "Link solc against static versions of libgcc and libstdc++ on supported platforms" OFF)
 option(STRICT_Z3_VERSION "Use the latest version of Z3" ON)
+option(PEDANTIC "Enable extra warnings and pedantic build flags. Treat all warnings as errors." ON)
 
 # Setup cccache.
 include(EthCcache)
@@ -48,6 +53,9 @@ include_directories(SYSTEM ${JSONCPP_INCLUDE_DIR})
 
 find_package(Threads)
 
+if(NOT PEDANTIC)
+  message(WARNING "-- Pedantic build flags turned off. Warnings will not make compilation fail. This is NOT recommended in development builds.")
+endif()
 # Figure out what compiler and system are we using
 include(EthCompilerSettings)
 
@@ -65,7 +73,7 @@ configure_file("${CMAKE_SOURCE_DIR}/cmake/templates/license.h.in" include/licens
 
 include(EthOptions)
 configure_project(TESTS)
-set(LATEST_Z3_VERSION "4.8.17")
+set(LATEST_Z3_VERSION "4.11.0")
 set(MINIMUM_Z3_VERSION "4.8.0")
 find_package(Z3)
 if (${Z3_FOUND})

diff --git a/docs/abi-spec.rst b/docs/abi-spec.rst
@@ -14,9 +14,14 @@ blok zinciri dışından hem de sözleşmeler arası etkileşimde bulunmanın st
 Veriler, bu spesifikasyonda açıklandığı gibi türlerine göre kodlanır. Şifreleme kendi
 kendini tanımlamaz ve bu nedenle şifreyi çözmek için bir şema gerekir.
 
+<<<<<<< HEAD
 Bir sözleşmenin arayüz fonksiyonlarının güçlü bir şekilde yazıldığını, derleme zamanında
 bilindiğini ve statik olduğunu varsayıyoruz. Tüm sözleşmelerin, çağırdıkları sözleşmelerin
 arayüz tanımlamalarına derleme zamanında sahip olacağını varsayıyoruz.
+=======
+We assume that the interface functions of a contract are strongly typed, known at compilation time and static.
+We assume that all contracts will have the interface definitions of any contracts they call available at compile-time.
+>>>>>>> v0.8.17
 
 Bu spesifikasyon, arayüzü dinamik olan veya başka bir şekilde yalnızca çalışma zamanında
 bilinen sözleşmeleri ele almaz.
@@ -27,12 +32,21 @@ bilinen sözleşmeleri ele almaz.
 Function Selector (Function Selector)
 ===========================================
 
+<<<<<<< HEAD
 Bir fonksiyon çağrısı için çağrı verisinin(call data) ilk dört baytı çağrılacak
 fonksiyonu belirtmektedir. Bu, fonksiyonun imzasının Keccak-256 hash'inin ilk (sol,
 büyük endian'da yüksek dereceden) dört baytıdır. İmza, veri konumu belirteci olmadan
 temel prototipin kanonik ifadesi, yani parametre türlerinin parantezli listesiyle
 birlikte fonksiyon adı olarak tanımlanır. Parametre tipleri tek bir virgülle ayrılır -
 boşluk kullanılmaz.
+=======
+The first four bytes of the call data for a function call specifies the function to be called. It is the
+first (left, high-order in big-endian) four bytes of the Keccak-256 hash of the signature of
+the function. The signature is defined as the canonical expression of the basic prototype without data
+location specifier, i.e.
+the function name with the parenthesised list of parameter types. Parameter types are split by a single
+comma — no spaces are used.
+>>>>>>> v0.8.17
 
 .. note::
     Bir fonksiyonun geri dönüş tipi bu imzanın bir parçası değildir. ref:`Solidity'nin
@@ -133,8 +147,13 @@ sütunda ise bunları temsil eden ABI tipleri verilmiştir.
    okuma gerekir. ABI'nin önceki bir sürümünde, okuma sayısı en kötü senaryoda toplam
    dinamik parametre sayısı ile doğrusal olarak ölçeklenmekteydi.
 
+<<<<<<< HEAD
 2. Bir değişken veya dizi elemanının verileri diğer verilerle iç içe geçmez ve yeniden
    konumlandırılabilir, yani yalnızca ilişkili "adresler" kullanabilirler.
+=======
+2. The data of a variable or an array element is not interleaved with other data and it is
+   relocatable, i.e. it only uses relative "addresses".
+>>>>>>> v0.8.17
 
 
 Şifrelemenin Formal Spesifikasyonu
@@ -250,7 +269,12 @@ Sözleşmeye göre:
     }
 
 
+<<<<<<< HEAD
 Böylece ``Foo`` örneğimiz için ``69`` ve ``true`` parametreleriyle ``baz`` ı çağırmak istersek, toplam 68 bayt iletiriz, bu da şu şekilde ayrılabilir:
+=======
+Thus, for our ``Foo`` example if we wanted to call ``baz`` with the parameters ``69`` and
+``true``, we would pass 68 bytes total, which can be broken down into:
+>>>>>>> v0.8.17
 
 - ``0xcdcd77c0``: Method ID. Bu, ``baz(uint32,bool)`` imzasının ASCII formunun Keccak hash'inin ilk 4 baytı olacak şekilde türetilecektir.
 - ``0x000000000000000000000000000000000000000000000045``: ilk parametre, 32 bayta doldurulmuş bir uint32 değeri ``69``
@@ -595,10 +619,18 @@ Hatalar aşağıdaki gibi görünür:
   * ``components``: tuple türleri için kullanılır (daha fazla bilgi aşağıdadır).
 
 .. note::
+<<<<<<< HEAD
   JSON dizisinde aynı ada ve hatta aynı imzaya sahip birden fazla hata(error) olabilir,
   örneğin hatalar akıllı sözleşmedeki farklı dosyalardan kaynaklanıyorsa veya başka bir
   akıllı sözleşmeden referans alınıyorsa. ABI için hatanın nerede tanımlandığı değil,
   yalnızca adı önemlidir.
+=======
+  There can be multiple errors with the same name and even with identical signature
+  in the JSON array; for example, if the errors originate from different
+  files in the smart contract or are referenced from another smart contract.
+  For the ABI, only the name of the error itself is relevant and not where it is
+  defined.
+>>>>>>> v0.8.17
 
 
 Örneğin,
@@ -644,6 +676,7 @@ JSON ile sonuçlanacaktır:
 Tuple tiplerinin kullanılması
 ------------------------------
 
+<<<<<<< HEAD
 İsimler bilinçli olarak ABI şifrelemesinin bir parçası olmamasına rağmen, son kullanıcıya
 gösterilmesini sağlamak için JSON'a dahil edilmeleri çok önemlidir. Yapı aşağıdaki şekilde
 iç içe geçmiştir:
@@ -654,6 +687,18 @@ kadar olan dize açıklaması ``tuple`` kelimesiyle ``type`` önekinde saklanır
 ve ardından ``[]`` ve ``[k]`` tamsayıları ``k`` ile bir dizi olacaktır. Tuple`ın bileşenleri
 daha sonra dizi tipinde olan ve üst düzey nesne ile aynı yapıya sahip olan ``components``
 üyesinde saklanır, ancak ``indexed`` öğesine bu durumda izin verilmez.
+=======
+Despite the fact that names are intentionally not part of the ABI encoding, they do make a lot of sense to be included
+in the JSON to enable displaying it to the end user. The structure is nested in the following way:
+
+An object with members ``name``, ``type`` and potentially ``components`` describes a typed variable.
+The canonical type is determined until a tuple type is reached and the string description up
+to that point is stored in ``type`` prefix with the word ``tuple``, i.e. it will be ``tuple`` followed by
+a sequence of ``[]`` and ``[k]`` with
+integers ``k``. The components of the tuple are then stored in the member ``components``,
+which is of an array type and has the same structure as the top-level object except that
+``indexed`` is not allowed there.
+>>>>>>> v0.8.17
 
 Örnek olarak, kod
 
@@ -735,13 +780,23 @@ JSON ile sonuçlanacaktır:
 Katı Şifreleme Modu
 ====================
 
+<<<<<<< HEAD
 Sıkı şifreleme modu, yukarıdaki resmi spesifikasyonda tanımlandığı gibi tam olarak aynı
 şifrelemeye neden olan moddur. Bu, ofsetlerin veri alanlarında çakışma yaratmadan mümkün
 olduğunca küçük olması gerektiği ve dolayısıyla hiçbir boşluğa izin verilmediği anlamına gelir.
 
 Genellikle, ABI şifre çözücüler sadece ofset işaretçilerini takip ederek basit bir şekilde
 yazılır, ancak bazı şifre çözücüler katı modu zorlayabilir. Solidity ABI şifre çözücü şu
 anda katı modu kullanmayı zorunlu kılmaz, ancak şifreleyici her zaman katı modda veri oluşturur.
+=======
+Strict encoding mode is the mode that leads to exactly the same encoding as defined in the formal specification above.
+This means that offsets have to be as small as possible while still not creating overlaps in the data areas, and thus no gaps are
+allowed.
+
+Usually, ABI decoders are written in a straightforward way by just following offset pointers, but some decoders
+might enforce strict mode. The Solidity ABI decoder currently does not enforce strict mode, but the encoder
+always creates data in strict mode.
+>>>>>>> v0.8.17
 
 Standart Olmayan Paket Modu
 =====================================
@@ -766,6 +821,7 @@ Ayrıca, struct'ların yanı sıra iç içe diziler de desteklenmez.
 
 Daha spesifik olarak:
 
+<<<<<<< HEAD
 - Şifreleme sırasında her şey in-place olarak şifrelenir. Bu, ABI şifrelemesi gibi
   baş ve kuyruk arasında bir ayrım olmadığı ve bir dizinin uzunluğunun şifrelenmediği
   anlamına gelir.
@@ -777,6 +833,20 @@ Daha spesifik olarak:
   uzunluk alanları olmadan şifrelenir.
 - Bir dizinin veya struct'ın parçası olmadığı sürece ``string`` veya ``bytes``
   şifrelemesinin sonuna doldurma uygulanmaz (bu durumda 32 baytın katlarına kadar doldurulur).
+=======
+- During the encoding, everything is encoded in-place. This means that there is
+  no distinction between head and tail, as in the ABI encoding, and the length
+  of an array is not encoded.
+- The direct arguments of ``abi.encodePacked`` are encoded without padding,
+  as long as they are not arrays (or ``string`` or ``bytes``).
+- The encoding of an array is the concatenation of the
+  encoding of its elements **with** padding.
+- Dynamically-sized types like ``string``, ``bytes`` or ``uint[]`` are encoded
+  without their length field.
+- The encoding of ``string`` or ``bytes`` does not apply padding at the end,
+  unless it is part of an array or struct (then it is padded to a multiple of
+  32 bytes).
+>>>>>>> v0.8.17
 
 Genel olarak, eksik uzunluk değeri nedeniyle dinamik olarak boyutlandırılmış iki
 öğe olduğu anda şifreleme belirsizleşir.
@@ -802,9 +872,15 @@ Fonksiyonları çağırırken paketlenmiş şifreleme kullanılmadığından, bi
 İndekslenmiş Event Parametrelerinin Şifrelenmesi
 =================================================
 
+<<<<<<< HEAD
 Değer türü olmayan indekslenmiş event parametreleri, yani diziler ve struct'lar
 doğrudan saklanmaz, bunun yerine bir şifrelemenin keccak256-hash'i saklanır. Bu
 şifreleme aşağıdaki gibi tanımlanmaktadır:
+=======
+Indexed event parameters that are not value types, i.e. arrays and structs are not
+stored directly but instead a Keccak-256 hash of an encoding is stored. This encoding
+is defined as follows:
+>>>>>>> v0.8.17
 
 - bir ``bytes`` ve ``string`` değerinin şifrelenmesi, herhangi bir doldurma veya
   uzunluk öneki olmaksızın sadece string içeriğinden ibarettir.

diff --git a/docs/assembly.rst b/docs/assembly.rst
@@ -256,10 +256,17 @@ Dinamik array'in uzunluğu array'in ilk slotunda saklanır ve diğer slotlara ar
 Hafıza Güvenliği
 ================
 
+<<<<<<< HEAD
 Inline assembly kullanmadan; derleyici(compiler), iyi tanımlanmış bir durumda kalmak için her zaman belleğe güvenir. Bu özellikle 
 :ref:`Yul IR üzerinden yeni kod oluşturma hattı Yul IR <ir-breaking-changes>` ile ilgilidir. Bu kod parçası yerel değişkenleri 
 stack üzerinden belleğe atarak stack-too-deep hatasından kaçınmayı sağlar ve eğer bazı kesin varsayımlara uyuyorsa ekstra 
 bellek optimizasyonları uygulayabilir.
+=======
+While we recommend to always respect Solidity's memory model, inline assembly allows you to use memory
+in an incompatible way. Therefore, moving stack variables to memory and additional memory optimizations are,
+by default, globally disabled in the presence of any inline assembly block that contains a memory operation
+or assigns to Solidity variables in memory.
+>>>>>>> v0.8.17
 
 
 Biz her ne kadar Solidity'nin kendi bellek modeline saygı gösterilmesini önersek de 

diff --git a/docs/bugs.json b/docs/bugs.json
@@ -1,9 +1,23 @@
 [
+    {
+        "uid": "SOL-2022-7",
+        "name": "StorageWriteRemovalBeforeConditionalTermination",
+        "summary": "Calling functions that conditionally terminate the external EVM call using the assembly statements ``return(...)`` or ``stop()`` may result in incorrect removals of prior storage writes.",
+        "description": "A call to a Yul function that conditionally terminates the external EVM call could result in prior storage writes being incorrectly removed by the Yul optimizer. This used to happen in cases in which it would have been valid to remove the store, if the Yul function in question never actually terminated the external call, and the control flow always returned back to the caller instead. Conditional termination within the same Yul block instead of within a called function was not affected. In Solidity with optimized via-IR code generation, any storage write before a function conditionally calling ``return(...)`` or ``stop()`` in inline assembly, may have been incorrectly removed, whenever it would have been valid to remove the write without the ``return(...)`` or ``stop()``. In optimized legacy code generation, only inline assembly that did not refer to any Solidity variables and that involved conditionally-terminating user-defined assembly functions could be affected.",
+        "link": "https://blog.soliditylang.org/2022/09/08/storage-write-removal-before-conditional-termination/",
+        "introduced": "0.8.13",
+        "fixed": "0.8.17",
+        "severity": "medium/high",
+        "conditions": {
+            "yulOptimizer": true
+        }
+    },
     {
         "uid": "SOL-2022-6",
         "name": "AbiReencodingHeadOverflowWithStaticArrayCleanup",
         "summary": "ABI-encoding a tuple with a statically-sized calldata array in the last component would corrupt 32 leading bytes of its first dynamically encoded component.",
         "description": "When ABI-encoding a statically-sized calldata array, the compiler always pads the data area to a multiple of 32-bytes and ensures that the padding bytes are zeroed. In some cases, this cleanup used to be performed by always writing exactly 32 bytes, regardless of how many needed to be zeroed. This was done with the assumption that the data that would eventually occupy the area past the end of the array had not yet been written, because the encoder processes tuple components in the order they were given. While this assumption is mostly true, there is an important corner case: dynamically encoded tuple components are stored separately from the statically-sized ones in an area called the *tail* of the encoding and the tail immediately follows the *head*, which is where the statically-sized components are placed. The aforementioned cleanup, if performed for the last component of the head would cross into the tail and overwrite up to 32 bytes of the first component stored there with zeros. The only array type for which the cleanup could actually result in an overwrite were arrays with ``uint256`` or ``bytes32`` as the base element type and in this case the size of the corrupted area was always exactly 32 bytes. The problem affected tuples at any nesting level. This included also structs, which are encoded as tuples in the ABI. Note also that lists of parameters and return values of functions, events and errors are encoded as tuples.",
+        "link": "https://blog.soliditylang.org/2022/08/08/calldata-tuple-reencoding-head-overflow-bug/",
         "introduced": "0.5.8",
         "fixed": "0.8.16",
         "severity": "medium",

diff --git a/docs/bugs_by_version.json b/docs/bugs_by_version.json
@@ -1737,6 +1737,7 @@
     },
     "0.8.13": {
         "bugs": [
+            "StorageWriteRemovalBeforeConditionalTermination",
             "AbiReencodingHeadOverflowWithStaticArrayCleanup",
             "DirtyBytesArrayToStorage",
             "InlineAssemblyMemorySideEffects",
@@ -1747,6 +1748,7 @@
     },
     "0.8.14": {
         "bugs": [
+            "StorageWriteRemovalBeforeConditionalTermination",
             "AbiReencodingHeadOverflowWithStaticArrayCleanup",
             "DirtyBytesArrayToStorage",
             "InlineAssemblyMemorySideEffects"
@@ -1755,14 +1757,21 @@
     },
     "0.8.15": {
         "bugs": [
+            "StorageWriteRemovalBeforeConditionalTermination",
             "AbiReencodingHeadOverflowWithStaticArrayCleanup"
         ],
         "released": "2022-06-15"
     },
     "0.8.16": {
-        "bugs": [],
+        "bugs": [
+            "StorageWriteRemovalBeforeConditionalTermination"
+        ],
         "released": "2022-08-08"
     },
+    "0.8.17": {
+        "bugs": [],
+        "released": "2022-09-08"
+    },
     "0.8.2": {
         "bugs": [
             "AbiReencodingHeadOverflowWithStaticArrayCleanup",

diff --git a/docs/contracts/function-modifiers.rst b/docs/contracts/function-modifiers.rst
@@ -111,8 +111,20 @@ Modifier'lar eklendikleri fonksiyonların parametrelerine veya return değerleri
 Eğer bir parametreyi bir modifier'da kullanmak istiyorsanız, o modifier'ı eklediğiniz yerde
 parametreyi de vermelisiniz. Fonksiyon çağırma yapısına benzer bir şekilde kullanılırlar.
 
+<<<<<<< HEAD
 Modifier'daki veya fonksiyon'daki return işlemi sadece o yazıldığı modifier'dan veya fonksiyon'dan
 çıkmaya yarar. Program akışı ``_`` işaretinin olduğu yerden çalışmaya devam eder.
+=======
+In function modifiers, it is necessary to specify when you want the function to which the modifier is
+applied to be run. The placeholder statement (denoted by a single underscore character ``_``) is used to
+denote where the body of the function being modified should be inserted. Note that the
+placeholder operator is different from using underscores as leading or trailing characters in variable
+names, which is a stylistic choice.
+
+Explicit returns from a modifier or function body only leave the current
+modifier or function body. Return variables are assigned and
+control flow continues after the ``_`` in the preceding modifier.
+>>>>>>> v0.8.17
 
 .. warning::
     Daha önceki Solidity versiyonlarında modifier'a sahip fonksiyonlarda ``return`` ifadesi farklı

diff --git a/docs/contracts/functions.rst b/docs/contracts/functions.rst
@@ -70,6 +70,7 @@ parametre olarak almasını isterseniz, aşağıdaki gibi bir yapı kullanabilir
 Fonksiyon parametreleri herhangi bir lokal değişken olarak kullanılaiblir ve ayrıca lokal
 değişkenlere atanabilirler.
 
+<<<<<<< HEAD
 .. note::
 
   Bir :ref:`external fonksiyon<external-function-calls>` çok boyutlu bir
@@ -80,6 +81,8 @@ değişkenlere atanabilirler.
   Bir :ref:`internal fonksiyon<external-function-calls>` o özelliği aktifleştirmeden
   de çok boyutlu bir diziyi parametre olarak alabilir.
 
+=======
+>>>>>>> v0.8.17
 .. index:: return array, return string, array, string, array of strings, dynamic array, variably sized array, return struct, struct
 
 Return Değişkenleri
@@ -134,11 +137,24 @@ Eğer fonksiyondan çıkmak için erkenden ``return`` kullanmanak istiyorsanız,
 bütün return değişkenlerini vermeniz gerekir.
 
 .. note::
+<<<<<<< HEAD
     Bazı tipleri internal olmayan fonksiyonlardan return edemezsiniz,
     örneğin, çok boyutlu dinamik boyutlu diziler ve structlar. Eğer
     ABI coder v2'yi ``pragma abicoder v2;`` şeklinde kodunuza eklerseniz
     daha fazla tip kullanılabilir olacaktır, ancak ``mapping`` tipi
     hâlâ bir akıllı sözleşme içerisinde sınırlıdır ve onları transfer edemezsiniz.
+=======
+    You cannot return some types from non-internal functions.
+    This includes the types listed below and any composite types that recursively contain them:
+
+    - mappings,
+    - internal function types,
+    - reference types with location set to ``storage``,
+    - multi-dimensional arrays (applies only to :ref:`ABI coder v1 <abi_coder>`),
+    - structs (applies only to :ref:`ABI coder v1 <abi_coder>`).
+
+    This restriction does not apply to library functions because of their different :ref:`internal ABI <library-selectors>`.
+>>>>>>> v0.8.17
 
 .. _multi-return: