diff --git a/CMakeLists.txt b/CMakeLists.txt index 426520383..c0865fb4c 100644 --- 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 index ae467f7c1..b82765813 100644 --- 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,6 +780,7 @@ 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. @@ -742,6 +788,15 @@ olduğunca küçük olması gerektiği ve dolayısıyla hiçbir boşluğa izin v 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 index 98d097a59..81dc60222 100644 --- 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 ` 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 index bdea0a7c2..03dafbe45 100644 --- 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 index 3e3847c9b..11ddd40b0 100644 --- 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 index 0b5f34aa0..c2534d371 100644 --- 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 index 6ab44c35d..8f52e92a9 100644 --- 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` çok boyutlu bir @@ -80,6 +81,8 @@ değişkenlere atanabilirler. Bir :ref:`internal fonksiyon` 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 `), + - structs (applies only to :ref:`ABI coder v1 `). + + This restriction does not apply to library functions because of their different :ref:`internal ABI `. +>>>>>>> v0.8.17 .. _multi-return: diff --git a/docs/contributing.rst b/docs/contributing.rst index 15efdc3ad..fb757f10d 100644 --- a/docs/contributing.rst +++ b/docs/contributing.rst @@ -30,8 +30,12 @@ Takım Toplantıları Tartışmak istediğiniz sorunlar veya pull request'ler varsa ya da ekibin ve katkıda bulunanların neler üzerinde çalıştığını duymak istiyorsanız, herkese açık takım toplantılarımıza katılabilirsiniz: +<<<<<<< HEAD - Pazartesi günleri saat 15:00 CET/CEST. Türkiye saati ile 16:00, - Çarşamba günleri 14:00 CET/CEST. +======= +- Mondays and Wednesdays at 3pm CET/CEST. +>>>>>>> v0.8.17 Her iki çağrı da `Jitsi `_ üzerinde gerçekleşir. diff --git a/docs/control-structures.rst b/docs/control-structures.rst index 50f609fa4..dac4bbe2c 100644 --- a/docs/control-structures.rst +++ b/docs/control-structures.rst @@ -141,8 +141,13 @@ hatalara da neden olur. ``f.value(x).gas(g)()`` kullanmaktı. Bu, Solidity 0.6.2'de kullanımdan kaldırıldı ve Solidity 0.7.0'dan beri kullanımı artık mümkün değil. +<<<<<<< HEAD Adlandırılmış Çağrılar ve Anonim Fonksiyon Parametreleri -------------------------------------------------------- +======= +Function Calls with Named Parameters +------------------------------------ +>>>>>>> v0.8.17 Aşağıdaki örnekte görüldüğü gibi, ``{ }`` içine alınmışlarsa, fonksiyon çağrısı argümanları herhangi bir sırayla ve tercihe bağlı isimle adlandırılabilir. @@ -167,11 +172,21 @@ Argüman listesi, fonksiyon bildirimindeki parametre listesiyle ve adıyla } +<<<<<<< HEAD Dikkate Alınmayan Fonksiyon Parametre Adları --------------------------------------------- Kullanılmayan parametrelerin adları (özellikle dönüş parametreleri) atlanabilir. Bu parametreler yığında bulunmaya devam eder, fakat erişilemezler. +======= +Omitted Names in Function Definitions +------------------------------------- + +The names of parameters and return values in the function declaration can be omitted. +Those items with omitted names will still be present on the stack, but they are +inaccessible by name. An omitted return value name +can still return a value to the caller by use of the ``return`` statement. +>>>>>>> v0.8.17 .. code-block:: solidity diff --git a/docs/examples/voting.rst b/docs/examples/voting.rst index 7c01a748d..470ef8737 100644 --- a/docs/examples/voting.rst +++ b/docs/examples/voting.rst @@ -188,6 +188,14 @@ oyu almış teklifi geri döndürecek. Olası İyileştirmeler ===================== +<<<<<<< HEAD Şu an tüm katılımcılara yetki vermek için çok sayıda işlem gerçekleştirilmesi gerekiyor. Daha iyi bir yöntem düşünebiliyor musunuz? +======= +Currently, many transactions are needed to +assign the rights to vote to all participants. +Moreover, if two or more proposals have the same +number of votes, ``winningProposal()`` is not able +to register a tie. Can you think of a way to fix these issues? +>>>>>>> v0.8.17 diff --git a/docs/installing-solidity.rst b/docs/installing-solidity.rst index e5df8a81a..547a4042e 100644 --- a/docs/installing-solidity.rst +++ b/docs/installing-solidity.rst @@ -351,8 +351,24 @@ Aşağıda Solidity'nin tüm geliştirmeleri için bağımlılıklar verilmişti gereksinimi karşılayan herhangi bir sürümle derleme yapabilirsiniz. Ancak bunu yaparsanız, SMT testlerini atlamak için lütfen ``scripts/tests.sh`` dosyasına ``--no-smt`` seçeneğini de eklemeyi unutmayın. +<<<<<<< HEAD Minimum Derleyici Sürümleri ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +======= +.. note:: + By default the build is performed in *pedantic mode*, which enables extra warnings and tells the + compiler to treat all warnings as errors. + This forces developers to fix warnings as they arise, so they do not accumulate "to be fixed later". + If you are only interested in creating a release build and do not intend to modify the source code + to deal with such warnings, you can pass ``-DPEDANTIC=OFF`` option to CMake to disable this mode. + Doing this is not recommended for general use but may be necessary when using a toolchain we are + not testing with or trying to build an older version with newer tools. + If you encounter such warnings, please consider + `reporting them `_. + +Minimum Compiler Versions +^^^^^^^^^^^^^^^^^^^^^^^^^ +>>>>>>> v0.8.17 Aşağıdaki C++ derleyicileri ve minimum sürümleri Solidity kod tabanını derleyebilir: diff --git a/docs/internals/layout_in_storage.rst b/docs/internals/layout_in_storage.rst index d51c2ce13..367a27ccd 100644 --- a/docs/internals/layout_in_storage.rst +++ b/docs/internals/layout_in_storage.rst @@ -143,7 +143,7 @@ Bir sözleşmenin depolama düzeni :ref:`standart JSON arayüzü ` her bir elemanın aşağıdaki forma sahip olduğu bir dizidir: -.. code:: +.. code-block:: json { @@ -167,7 +167,7 @@ Yukarıdaki örnek, ``fileA`` kaynak biriminden ``contract A { uint x; }`` depol Verilen ``typep``, bu durumda ``t_uint256``, ``types`` içinde şu forma sahip bir elemanı temsil eder: -.. code:: +.. code-block:: json { "encoding": "inplace", @@ -223,7 +223,7 @@ ve iç içe geçmiş türler içeren bir sözleşme ve depolama düzeni gösteri bytes b1; } -.. code:: json +.. code-block:: json { "storage": [ diff --git a/docs/internals/optimizer.rst b/docs/internals/optimizer.rst index 2c0cf1112..344d7a861 100644 --- a/docs/internals/optimizer.rst +++ b/docs/internals/optimizer.rst @@ -23,7 +23,15 @@ olarak Yul kodu için oluşturulan Yul iyileştiriciyi, örneğin ABI kodlayıc Bir Solidity kaynağına özel olarak optimize edilmiş bir Yul IR üretmek için ``solc --ir-optimized --optimize`` kullanılabilir. Benzer şekilde, bağımsız bir Yul modu için ``solc --strict-assembly --optimize`` kullanılabilir. +<<<<<<< HEAD Aşağıda hem optimize edici modüller hem de optimizasyon adımları hakkında daha fazla ayrıntı bulabilirsiniz. +======= +.. note:: + The `peephole optimizer `_ and the inliner are always + enabled by default and can only be turned off via the :ref:`Standard JSON `. + +You can find more details on both optimizer modules and their optimization steps below. +>>>>>>> v0.8.17 Solidity Kodunu Optimize Etmenin Faydaları ============================================ @@ -668,7 +676,7 @@ olan ifadeler değiştirilmeden kullanılır. Çakışan İfade değerleri de a - "unused", "undecided" -> "undecided" - "unused", "used" -> "used" -- "undecided, "used" -> "used" +- "undecided", "used" -> "used" For-döngüleri açısından koşul, gövde ve son bölüm, koşulda birleşen kontrol akışı dikkate alınarak iki kez kontrol edilir. Başka bir ifadeyle, temel olarak üç kontrol akış yolu diff --git a/docs/introduction-to-smart-contracts.rst b/docs/introduction-to-smart-contracts.rst index 6ae79f41a..f9a3cee5e 100644 --- a/docs/introduction-to-smart-contracts.rst +++ b/docs/introduction-to-smart-contracts.rst @@ -176,9 +176,17 @@ Web uygulamaları gibi Ethereum istemcileri, blok zincirinde yayılan (emit) bu Event yayılır yayılmaz, veri alıcısı ``from``, ``to`` ve ``amount`` argümanlarını alır, bu da alım satım işlemlerinin takip edilmesini mümkün kılar. +<<<<<<< HEAD Bu olayı(event) dinlemek amacıyla, ``Coin`` sözleşme nesnesini oluşturmak için `web3.js `_ kütüphanesini kullanan aşağıdaki JavaScript kodunu kullanabilirsiniz. Ve herhangi bir kullanıcı arayüzü (user interface), otomatik olarak oluşturulan ``balances`` fonksiyonunu yukarıdan sizin için çağırır:: +======= +To listen for this event, you could use the following +JavaScript code, which uses `web3.js `_ to create the ``Coin`` contract object, +and any user interface calls the automatically generated ``balances`` function from above: + +.. code-block:: javascript +>>>>>>> v0.8.17 Coin.Sent().watch({}, '', function(error, result) { if (!error) { @@ -473,10 +481,15 @@ tekrarlamalı çağrılar yerine döngüler tercih edileceği anlamına gelir. A bir mesaj çağrısında gazın sadece 63 / 64'ü iletilebilir; bu, pratikte 1000 bit'ten daha az bir alan sınırlamasına neden olur. -.. index:: delegatecall, callcode, library +.. index:: delegatecall, library +<<<<<<< HEAD Delegatecall / Çağrı Kodu ve Kütüphaneler ========================================== +======= +Delegatecall and Libraries +========================== +>>>>>>> v0.8.17 Bir mesaj çağrısı ile temelde aynı anlama gelen **delegatecall**, hedef adresteki kodun arama sözleşmesi bağlamında (yani adresinde) yürütülmesi ve diff --git a/docs/layout-of-source-files.rst b/docs/layout-of-source-files.rst index 8abf52e12..b365f91b3 100644 --- a/docs/layout-of-source-files.rst +++ b/docs/layout-of-source-files.rst @@ -34,11 +34,24 @@ SPDX lisans tanımlayıcılarının nasıl kullanılacağı hakkında daha fazla .. _pragma: +<<<<<<< HEAD Pragmalar ========== ``Pragma`` anahtar sözcüğü, belirli derleyici özelliklerini veya kontrollerini etkinleştirmek için kullanılır. Bir pragma yönergesi, her zaman bir kaynak dosya için yereldir, bu nedenle pragmayı tüm projenizde etkinleştirmek istiyorsanız tüm dosyalarınıza eklemeniz gerekir. Başka bir dosyayı :ref:`içe aktarırsanız` o dosyadaki pragma, içe aktarılan dosyaya otomatik olarak _*uygulanmaz*._ .. index:: ! pragma, version +======= +Pragmas +======= + +The ``pragma`` keyword is used to enable certain compiler features +or checks. A pragma directive is always local to a source file, so +you have to add the pragma to all your files if you want to enable it +in your whole project. If you :ref:`import` another file, the pragma +from that file does *not* automatically apply to the importing file. + +.. index:: ! pragma;version +>>>>>>> v0.8.17 .. _version_pragma: @@ -60,14 +73,31 @@ bunlar `npm `_ tarafından kulla Yalnızca, derleyiciye kendi sürümünün, pragmanın gerektirdiği sürüm ile uyumlu olup olmadığını kontrol etmesi için yönerge verir. Sürümler uyumlu değilse derleyici hata verir. +<<<<<<< HEAD ABI Kodlayıcı Pragması ----------------------- +======= +.. index:: ! ABI coder, ! pragma; abicoder, pragma; ABIEncoderV2 +.. _abi_coder: + +ABI Coder Pragma +---------------- +>>>>>>> v0.8.17 ``pragma abicoder v1`` veya ``pragma abicoder v2`` kullanarak ABI kodlayıcı ile kod çözücü iki uygulama arasında seçim yapabilirsiniz. +<<<<<<< HEAD Yeni ABI kodlayıcı (v2) keyfi olarak iç içe geçmiş dizileri ve yapıları kodlama(encode) ve kod çözme(decode) yapabilir . Daha az optimal kod üretebilir ve eski kodlayıcı kadar test edilmemiştir, ancak Solidity 0.6.0'dan itibaren deneysel olmayan olarak kabul edilir. Yine de ``pragma abicoder v2;`` kullanarak açıkça etkinleştirmeniz gerekir. Solidity 0.8.0'dan itibaren varsayılan olarak etkinleştirileceğinden, ``pragma abicoder v1;`` kullanarak eski kodlayıcıyı seçme seçeneği vardır. +======= +The new ABI coder (v2) is able to encode and decode arbitrarily nested +arrays and structs. Apart from supporting more types, it involves more extensive +validation and safety checks, which may result in higher gas costs, but also heightened +security. It is considered +non-experimental as of Solidity 0.6.0 and it is enabled by default starting +with Solidity 0.8.0. The old ABI coder can still be selected using ``pragma abicoder v1;``. +>>>>>>> v0.8.17 Yeni kodlayıcı tarafından desteklenen türler, eskisi tarafından desteklenenlerin katı bir üst kümesidir. Bunu kullanan sözleşmeler, kullanmayanlarla sınırlama olmadan etkileşime girebilir. Bunun tersi ancak, ``abicoder v2`` dışı sözleşme, yalnızca yeni kodlayıcı tarafından desteklenen kod çözme türlerini gerektirecek çağrılarda bulunmaya çalışmadığı sürece mümkündür. Aksi halde, derleyici bu çağrıları tespit ederek hata verebilir. Sözleşmeniz için ``abicoder v2`` yi etkinleştirmeniz hatanın ortadan kalkması için yeterlidir. @@ -78,8 +108,12 @@ Yeni kodlayıcı tarafından desteklenen türler, eskisi tarafından desteklenen .. note:: Solidity 0.7.4'e kadar, ``pragma experimental ABIEncoderV2`` kullanarak ABI kodlayıcı v2'yi seçmek mümkündü, ancak varsayılan olduğu için kodlayıcı v1'i açık bir şekilde seçmek mümkün değildi. +<<<<<<< HEAD .. index:: ! pragma, deneysel +======= +.. index:: ! pragma; experimental +>>>>>>> v0.8.17 .. _experimental_pragma: Deneysel Pragma @@ -87,6 +121,7 @@ Deneysel Pragma İkinci pragma deneysel pragmadır. Derleyicinin veya dilin henüz varsayılan olarak etkinleştirilmemiş özelliklerini etkinleştirmek için kullanılabilir. Şu anda, aşağıdaki deneysel pragmalar desteklenmektedir: +.. index:: ! pragma; ABIEncoderV2 ABIEncoderV2 ~~~~~~~~~~~~ @@ -94,6 +129,7 @@ ABIEncoderV2 ABI kodlayıcı v2 artık deneysel kabul edilmediğinden Solidity 0.7.4 sonrasında ``pragma abicoder v2`` aracılığıyla seçilebilir (lütfen yukarıya bakın). +.. index:: ! pragma; SMTChecker .. _smt_checker: SMTChecker diff --git a/docs/metadata.rst b/docs/metadata.rst index 9942b5b44..e225f0841 100644 --- a/docs/metadata.rst +++ b/docs/metadata.rst @@ -10,7 +10,18 @@ Solidity derleyicisi derlenen sözleşme hakkında bilgiler içeren "şözleşme Derleyici varsayılan şeklinde meta veri dosyasının IPFS hash'ini bayt kodun sonuna ekler (detaylar için aşağıya göz atınız). Böylelikle meta veri merkezi bir veri sağlayıcısına bağlı kalmadan doğrulanmış bir şekilde indirebilirsiniz. Bu konuda diğer seçenekler Swarm hash'ini kullanmak veya meta veri hash'ini bayt kodun sonuna eklememektir. Bu seçenekler :ref:`Standard JSON Arayüzü` üzerinden ayarlanabilir. +<<<<<<< HEAD Meta veri dosyasına erişilebilmesi için dosyayı IPFS, Swarm veya başka bir serviste yayınlamanız gerekmektedir. Dosyayı ``SözleşmeAdı_meta.json`` adında bir dosya oluşturan ``solc --metadata`` komutunu kullanarak yaratabilirsiniz. Dosya kaynak kodu dosyalarının IPFS ve Swarm hash'lerini içerdiği için bütün kaynak kodu dosyalarını ve meta veri dosyasını yüklemeniz gerekmektedir. +======= +You have to publish the metadata file to IPFS, Swarm, or another service so +that others can access it. You create the file by using the ``solc --metadata`` +command together with the ``--output-dir`` parameter. Without the parameter, +the metadata will be written to standard output. +The metadata contains IPFS and Swarm references to the source code, so you have to +upload all source files in addition to the metadata file. For IPFS, the hash contained +in the CID returned by ``ipfs add`` (not the direct sha2-256 hash of the file) +shall match with the one contained in the bytecode. +>>>>>>> v0.8.17 Meta veri dosyası aşağıdaki formattadır. Fakat aşağıdaki örnek okuması kolay şekilde gösterilmektedir. Normalde düzgün şekilde formatlanmış meta veri tırnak işaretlerini doğru şekilde kullanmalı, metindeki boşlukları en aza indirmeli ve JSON nesnesinin anahtarlarını tutarlı bir formatlamaya ulaşmak için sıralamalıdır. Normalde JSON dosyalarında yorum satırlarına müsade edilmezken burada yalnızca gösterim amaçlı olarak eklenmiştir. @@ -24,6 +35,7 @@ Meta veri dosyası aşağıdaki formattadır. Fakat aşağıdaki örnek okuması // Mecburi: Derleyici hakkında detaylar. İçeriği kullanılan dile // göre değişebilir. "compiler": { +<<<<<<< HEAD // Solidity için mecburi: Derleyici sürümü. "version": "0.4.6+commit.2dabbdf0.Emscripten.clang", // Opsiyonel: Bu çıktıyı elde etmek için kullanılan @@ -42,6 +54,24 @@ Meta veri dosyası aşağıdaki formattadır. Fakat aşağıdaki örnek okuması // ("content" kullanıldığında mecburi değildir, aşağıya bakınız) "urls": [ "bzzr://56ab..." ], // Opsiyonel: Kaynak kodunda belirtilen şekilde SPDX lisans kodu +======= + // Required for Solidity: Version of the compiler + "version": "0.8.2+commit.661d1103", + // Optional: Hash of the compiler binary which produced this output + "keccak256": "0x123..." + }, + // Required: Compilation source files/source units, keys are file paths + "sources": + { + "myDirectory/myFile.sol": { + // Required: keccak256 hash of the source file + "keccak256": "0x123...", + // Required (unless "content" is used, see below): Sorted URL(s) + // to the source file, protocol is more or less arbitrary, but an + // IPFS URL is recommended + "urls": [ "bzz-raw://7d7a...", "dweb:/ipfs/QmN..." ], + // Optional: SPDX license identifier as given in the source file +>>>>>>> v0.8.17 "license": "MIT" }, "destructible": { @@ -55,7 +85,11 @@ Meta veri dosyası aşağıdaki formattadır. Fakat aşağıdaki örnek okuması // Mecburi: Derleyici ayarları "settings": { +<<<<<<< HEAD // Solidity için mecburi: yeniden eşlemelerin sıralı listesi +======= + // Required for Solidity: Sorted list of import remappings +>>>>>>> v0.8.17 "remappings": [ ":g=/dir" ], // Opsiyonel: Optimize edici ayarları. "enabled" vs "runs" anahtarları // artık kullanılmamaktadır ve geriye dönük uyumluluk için verilmiştir. @@ -82,15 +116,24 @@ Meta veri dosyası aşağıdaki formattadır. Fakat aşağıdaki örnek okuması } }, "metadata": { +<<<<<<< HEAD // Girdi json'da kullanılan ayarın aynısı. Varsayılan: "false" +======= + // Reflects the setting used in the input json, defaults to "false" +>>>>>>> v0.8.17 "useLiteralContent": true, // Girdi json'da kullanılan ayarın aynısı. Varsayılan: "ipfs" "bytecodeHash": "ipfs" }, +<<<<<<< HEAD // Solidity için mecburi: Bu meta veri hangisi için yaratıldıysa o // dosya ile sözleşme veya kütüphanenin adı. +======= + // Required for Solidity: File path and the name of the contract or library this + // metadata is created for. +>>>>>>> v0.8.17 "compilationTarget": { - "myFile.sol": "MyContract" + "myDirectory/myFile.sol": "MyContract" }, // Solidity için mecburi: Kullanılan kütüphanelerin adresleri "libraries": { @@ -100,12 +143,75 @@ Meta veri dosyası aşağıdaki formattadır. Fakat aşağıdaki örnek okuması // Mecburi: Sözleşme için oluşturulan bilgiler "output": { +<<<<<<< HEAD // Mecburi: Sözleşmenin ABI tanımı "abi": [/* ... */], // Mecburi: Sözleşmenin NatSpec kullanıcı dokümantasyonu "userdoc": [/* ... */], // Mecburi: Sözleşmenin NatSpec geliştirici dokümantasyonu "devdoc": [/* ... */] +======= + // Required: ABI definition of the contract. See "Contract ABI Specification" + "abi": [/* ... */], + // Required: NatSpec developer documentation of the contract. + "devdoc": { + "version": 1 // NatSpec version + "kind": "dev", + // Contents of the @author NatSpec field of the contract + "author": "John Doe", + // Contents of the @title NatSpec field of the contract + "title": "MyERC20: an example ERC20" + // Contents of the @dev NatSpec field of the contract + "details": "Interface of the ERC20 standard as defined in the EIP. See https://eips.ethereum.org/EIPS/eip-20 for details", + "methods": { + "transfer(address,uint256)": { + // Contents of the @dev NatSpec field of the method + "details": "Returns a boolean value indicating whether the operation succeeded. Must be called by the token holder address", + // Contents of the @param NatSpec fields of the method + "params": { + "_value": "The amount tokens to be transferred", + "_to": "The receiver address" + } + // Contents of the @return NatSpec field. + "returns": { + // Return var name (here "success") if exists. "_0" as key if return var is unnamed + "success": "a boolean value indicating whether the operation succeeded" + } + } + }, + "stateVariables": { + "owner": { + // Contents of the @dev NatSpec field of the state variable + "details": "Must be set during contract creation. Can then only be changed by the owner" + } + } + "events": { + "Transfer(address,address,uint256)": { + "details": "Emitted when `value` tokens are moved from one account (`from`) toanother (`to`)." + "params": { + "from": "The sender address" + "to": "The receiver address" + "value": "The token amount" + } + } + } + }, + // Required: NatSpec user documentation of the contract + "userdoc": { + "version": 1 // NatSpec version + "kind": "user", + "methods": { + "transfer(address,uint256)": { + "notice": "Transfers `_value` tokens to address `_to`" + } + }, + "events": { + "Transfer(address,address,uint256)": { + "notice": "`_value` tokens have been moved from `from` to `to`" + } + } + } +>>>>>>> v0.8.17 } } @@ -141,8 +247,13 @@ yüklenen bayt kodun sonuna ekler. 0x64 's' 'o' 'l' 'c' 0x43 <3 bayt sürüm kodlaması> 0x00 0x33 +<<<<<<< HEAD Meta veriyi indirmek için yüklenen bayt kodun sonu bu örüntüye uyuyor mu diye bakılabilir ve elde edilen IPFS hash'i ile dosya indirilebilir. +======= +So in order to retrieve the data, the end of the deployed bytecode can be checked +to match that pattern and the IPFS hash can be used to retrieve the file (if pinned/published). +>>>>>>> v0.8.17 solc'in tamamlanmış sürümleri yukarıdaki 3 baytlık kodlama ile kodlanırken (her bir "büyük", "küçük", ve "yama" sürümü için birer bayt), tamamlanmamış @@ -170,14 +281,28 @@ bir bileşen (örn. Mist veya başka bir cüzdan) sözleşmenin kodunu indirir. sonra bu koddan IPFS/Swarm hash'ini elde eder ve meta veri dosyası indirilir. Bu dosya yukarıdaki yapıya uygun şekilde JSON formatında çözülür. +<<<<<<< HEAD İlgili bileşen, ABI'ı otomatik olarak basit bir kullanıcı arayüzü oluşturmak için kullanabilir. +======= +The metadata is used in the following way: A component that wants to interact +with a contract (e.g. a wallet) retrieves the code of the contract. +It decodes the CBOR encoded section containing the IPFS/Swarm hash of the +metadata file. With that hash, the metadata file is retrieved. That file +is JSON-decoded into a structure like above. +>>>>>>> v0.8.17 Ek olarak cüzdan, kullanıcı bir sözleşmeyle etkileşime geçerken kullanıcıdan işlem için imza onayı istemenin yanında kullanıcıya bir onay mesajı göstermek için NatSpec kullanıcı dokümantasyonunu kullanabilir. +<<<<<<< HEAD Daha fazla bilgi için :doc:`Ethereum Natural Language Specification (NatSpec) format ` ını okuyunuz. +======= +Furthermore, the wallet can use the NatSpec user documentation to display a human-readable confirmation message to the user +whenever they interact with the contract, together with requesting +authorization for the transaction signature. +>>>>>>> v0.8.17 Kaynak Kodu Doğrulama için Kullanım ==================================== diff --git a/docs/natspec-format.rst b/docs/natspec-format.rst index 3ca09b8c4..f89a96b6c 100644 --- a/docs/natspec-format.rst +++ b/docs/natspec-format.rst @@ -182,7 +182,7 @@ tasarlanmıştır. Yukarıdaki sözleşme ``ex1.sol`` olarak kaydedilirse, belgeleri kullanarak oluşturabilirsiniz: -.. code:: +.. code-block:: shell solc --userdoc --devdoc ex1.sol @@ -201,7 +201,7 @@ Kullanıcı Dokümantasyonu Yukarıdaki dokümantasyon çıktı olarak aşağıdaki kullanıcı dokümantasyonu JSON dosyasını üretecektir: -.. code:: +.. code-block:: json { "version" : 1, @@ -227,7 +227,7 @@ Geliştirici Dokümantasyonu Kullanıcı dokümantasyon dosyasının yanı sıra, bir geliştirici dokümantasyon JSON dosyası da üretilmeli ve aşağıdaki gibi görünmelidir: -.. code:: +.. code-block:: json { "version" : 1, diff --git a/docs/security-considerations.rst b/docs/security-considerations.rst index b0b0714bd..ec03de371 100644 --- a/docs/security-considerations.rst +++ b/docs/security-considerations.rst @@ -93,8 +93,13 @@ yapmasına izin verecektir: } } +<<<<<<< HEAD Yeniden Giriş'den(Re-entrancy) kaçınmak için, aşağıda daha ayrıntılı olarak açıklandığı gibi Checks-Effects-Interactions kalıbını kullanabilirsiniz: +======= +To avoid re-entrancy, you can use the Checks-Effects-Interactions pattern as +demonstrated below: +>>>>>>> v0.8.17 .. code-block:: solidity @@ -112,10 +117,24 @@ Checks-Effects-Interactions kalıbını kullanabilirsiniz: } } +<<<<<<< HEAD Yeniden girişin yalnızca Ether aktarımının değil, başka bir sözleşmedeki herhangi bir fonksiyon çağrısının da bir etkisi olduğunu unutmayın. Ayrıca, çoklu sözleşme içeren durumları da hesaba katmanız gerekmektedir. Çağrılan bir sözleşme, bağımlı olduğunuz başka bir sözleşmenin yapısını değiştirebilir. +======= +The Checks-Effects-Interactions pattern ensures that all code paths through a contract complete all required checks +of the supplied parameters before modifying the contract's state (Checks); only then it makes any changes to the state (Effects); +it may make calls to functions in other contracts *after* all planned state changes have been written to +storage (Interactions). This is a common foolproof way to prevent *re-entrancy attacks*, where an externally called +malicious contract is able to double-spend an allowance, double-withdraw a balance, among other things, by using logic that calls back into the +original contract before it has finalized its transaction. + +Note that re-entrancy is not only an effect of Ether transfer but of any +function call on another contract. Furthermore, you also have to take +multi-contract situations into account. A called contract could modify the +state of another contract you depend on. +>>>>>>> v0.8.17 Gas Limiti ve Döngüler ======================= diff --git a/docs/smtchecker.rst b/docs/smtchecker.rst index caa901713..6d2f4373b 100644 --- a/docs/smtchecker.rst +++ b/docs/smtchecker.rst @@ -684,7 +684,7 @@ Types that are not yet supported are abstracted by a single 256-bit unsigned integer, where their unsupported operations are ignored. For more details on how the SMT encoding works internally, see the paper -`SMT-based Verification of Solidity Smart Contracts `_. +`SMT-based Verification of Solidity Smart Contracts `_. Function Calls ============== diff --git a/docs/types/operators.rst b/docs/types/operators.rst index cd7ff1769..55bb4fbb3 100644 --- a/docs/types/operators.rst +++ b/docs/types/operators.rst @@ -11,7 +11,16 @@ Aritmetik operatörler ve bit operatörleri, iki işlenen aynı türe sahip olma sağ işlenenin türünü kullanın, 3. İki seçenek de uygulanamıyorsa işleme izin verilmez. +<<<<<<< HEAD İşlenenlerden birinin :ref:`gerçek sayı ` olması durumunda, ilk önce değeri tutabilen en küçük tür olan "mobil türe" dönüştürülür (aynı bit genişliğindeki işaretsiz türler, işaretli türlerden "daha küçük" olarak kabul edilir) . +======= +In case one of the operands is a :ref:`literal number ` it is first converted to its +"mobile type", which is the smallest type that can hold the value +(unsigned types of the same bit-width are considered "smaller" than the signed types). +If both are literal numbers, the operation is computed with effectively unlimited precision in +that the expression is evaluated to whatever precision is necessary so that none is lost +when the result is used with a non-literal type. +>>>>>>> v0.8.17 Her ikisi de gerçek sayıysa, işlem keyfi bir kesinlikle hesaplanır. diff --git a/docs/types/reference-types.rst b/docs/types/reference-types.rst index c604e5232..27c82abca 100644 --- a/docs/types/reference-types.rst +++ b/docs/types/reference-types.rst @@ -59,7 +59,14 @@ Data locations are not only relevant for persistency of data, but also for the s delete x; // diziyi temizler, ayrıca y'yi değiştirir // Aşağıdakiler çalışmıyor; depolamada yeni bir geçici adsız dizi oluşturması gerekir, ancak depolama "statik olarak" tahsis edilir: / // y = memoryArray; +<<<<<<< HEAD // İşaretçiyi "sıfırlayacağı" için bu da işe yaramaz, ancak işaret edebileceği mantıklı bir konum yoktur. +======= + // Similarly, "delete y" is not valid, as assignments to local variables + // referencing storage objects can only be made from existing storage objects. + // It would "reset" the pointer, but there is no sensible location it could point to. + // For more details see the documentation of the "delete" operator. +>>>>>>> v0.8.17 // delete y; g(x); // g'yi çağırır, x'e bir referans verir h(x); // h'yi çağırır ve bellekte bağımsız, geçici bir kopya oluşturur @@ -283,9 +290,19 @@ Dizi Üyeleri contract ArrayContract { uint[2**20] aLotOfIntegers; +<<<<<<< HEAD // Aşağıdakilerin bir çift dinamik dizi değil, dinamik bir çift dizisi (yani, iki uzunluktaki sabit boyutlu diziler) olduğuna dikkat edin. // Bu nedenle, T[], T'nin kendisi bir dizi olsa bile, her zaman dinamik bir T dizisidir. // Tüm durum değişkenleri için veri konumu depolamadır. +======= + // Note that the following is not a pair of dynamic arrays but a + // dynamic array of pairs (i.e. of fixed size arrays of length two). + // In Solidity, T[k] and T[] are always arrays with elements of type T, + // even if T itself is an array. + // Because of that, bool[2][] is a dynamic array of elements + // that are bool[2]. This is different from other languages, like C. + // Data location for all state variables is storage. +>>>>>>> v0.8.17 bool[2][] pairsOfFlags; // newPairs bellekte saklanır - tek olasılık diff --git a/docs/types/value-types.rst b/docs/types/value-types.rst index b3f6911fa..81d23494e 100644 --- a/docs/types/value-types.rst +++ b/docs/types/value-types.rst @@ -180,19 +180,38 @@ türüne dönüştürülebilir. Sözleşme türü için, bu dönüştürmeye yal .. note:: ``address`` türünde bir değişkene ihtiyacınız varsa ve buna Ether göndermeyi planlıyorsanız, bu gereksinimi görünür kılmak için türünü ``address payable`` olarak bildirin. Ayrıca, bu ayrımı veya dönüşümü mümkün olduğunca erken yapmaya çalışın. +<<<<<<< HEAD Operatörler: +======= + The distinction between ``address`` and ``address payable`` was introduced with version 0.5.0. + Also starting from that version, contracts are not implicitly convertible to the ``address`` type, but can still be explicitly converted to + ``address`` or to ``address payable``, if they have a receive or payable fallback function. + + +Operators: +>>>>>>> v0.8.17 * ``<=``, ``<``, ``==``, ``!=``, ``>=`` ve ``>`` .. warning:: +<<<<<<< HEAD Daha büyük bir bayt boyutu kullanan bir türü bir ``address``e, örneğin ``bytes32``ye dönüştürürseniz, ``address`` kısaltılır. Dönüştürme belirsizliğini azaltmak için sürüm 0.4.24 ve derleyici kuvvetinin daha yüksek sürümü, dönüştürmede kesmeyi açık hale getirirsiniz. Örneğin, ``0x111122223333444455556666777788889999AAAABBBBCCCCDDDDEEEEFFFFCCC`` 32 bayt değerini alın. +======= + If you convert a type that uses a larger byte size to an ``address``, for example ``bytes32``, then the ``address`` is truncated. + To reduce conversion ambiguity, starting with version 0.4.24, the compiler will force you to make the truncation explicit in the conversion. + Take for example the 32-byte value ``0x111122223333444455556666777788889999AAAABBBBCCCCDDDDEEEEFFFFCCCC``. +>>>>>>> v0.8.17 ``address(uint160(bytes20(b)))`` kullanabilirsiniz, bu da ``0x111122223333444455556666777788889999aAaa`` ile sonuçlanır, veya ``0x777788889999AaAAbBbbCccccddDdeeeEfFFfCcCc`` ile sonuçlanan ``address(uint160(uint256(b)))`` i kullanabilirsiniz. .. note:: +<<<<<<< HEAD ``address`` ve ``address payable`` arasındaki ayrım, 0.5.0 sürümüyle tanıtıldı. Ayrıca bu versiyondan başlayarak, sözleşmeler adres türünden türetilmez, ancak yine de bir alma veya ödeme geri dönüş fonksiyonu varsa, açıkça ``address`` e veya ``address payable`` a dönüştürülebilir. +======= + Mixed-case hexadecimal numbers conforming to `EIP-55 `_ are automatically treated as literals of the ``address`` type. See :ref:`Address Literals`. +>>>>>>> v0.8.17 .. _members-of-addresses: @@ -288,8 +307,14 @@ Her üç fonksiyon, ``call``, ``delegatecall`` ve ``staticcall`` çok düşük d * ``code`` and ``codehash`` +<<<<<<< HEAD Herhangi bir akıllı sözleşme için dağıtılan kodu sorgulayabilirsiniz. EVM bayt kodunu boş olabilecek bir ``bytes memory`` olarak almak için ``.code`` kullanın. ``.codehash`` kullanın, bu kodun Keccak-256 karmasını alın (``bytes32`` olarak). ``addr.codehash``in ``keccak256(addr.code)`` kullanmaktan daha ucuz olduğunu unutmayın. +======= +You can query the deployed code for any smart contract. Use ``.code`` to get the EVM bytecode as a +``bytes memory``, which might be empty. Use ``.codehash`` to get the Keccak-256 hash of that code +(as a ``bytes32``). Note that ``addr.codehash`` is cheaper than using ``keccak256(addr.code)``. +>>>>>>> v0.8.17 .. note:: Tüm sözleşmeler ``address`` türüne dönüştürülebilir, bu nedenle ``address(this).balance`` kullanılarak mevcut sözleşmenin bakiyesini sorgulamak mümkündür. diff --git a/docs/using-the-compiler.rst b/docs/using-the-compiler.rst index ab8e83cea..95463b857 100644 --- a/docs/using-the-compiler.rst +++ b/docs/using-the-compiler.rst @@ -605,6 +605,7 @@ Girdi Açıklaması Hata Türleri ~~~~~~~~~~~~~~~ +<<<<<<< HEAD 1. ``JSONError``: JSON girdisi gerekli biçime uymuyor, örneğin girdi bir JSON nesnesi değil, dil desteklenmiyor vb. 2. ``IOError``: Çözümlenemeyen URL veya sağlanan kaynaklardaki hash uyuşmazlığı gibi IO ve içe aktarma işleme hataları. 3. ``ParserError``: Kaynak kodu dil kurallarına uygun değil. @@ -619,6 +620,23 @@ Hata Türleri 12. ``FatalError``: Ölümcül hata doğru şekilde işlenmedi - bu bir sorun olarak raporlanmalıdır. 13. ``Warning``: Derlemeyi durdurmayan, ancak mümkünse ele alınması gereken bir uyarı. 14. ``Info``: Derleyicinin kullanıcının yararlı bulabileceğini düşündüğü, ancak tehlikeli olmayan ve mutlaka ele alınması gerekmeyen bilgiler. +======= +1. ``JSONError``: JSON input doesn't conform to the required format, e.g. input is not a JSON object, the language is not supported, etc. +2. ``IOError``: IO and import processing errors, such as unresolvable URL or hash mismatch in supplied sources. +3. ``ParserError``: Source code doesn't conform to the language rules. +4. ``DocstringParsingError``: The NatSpec tags in the comment block cannot be parsed. +5. ``SyntaxError``: Syntactical error, such as ``continue`` is used outside of a ``for`` loop. +6. ``DeclarationError``: Invalid, unresolvable or clashing identifier names. e.g. ``Identifier not found`` +7. ``TypeError``: Error within the type system, such as invalid type conversions, invalid assignments, etc. +8. ``UnimplementedFeatureError``: Feature is not supported by the compiler, but is expected to be supported in future versions. +9. ``InternalCompilerError``: Internal bug triggered in the compiler - this should be reported as an issue. +10. ``Exception``: Unknown failure during compilation - this should be reported as an issue. +11. ``CompilerError``: Invalid use of the compiler stack - this should be reported as an issue. +12. ``FatalError``: Fatal error not processed correctly - this should be reported as an issue. +13. ``YulException``: Error during Yul Code generation - this should be reported as an issue. +14. ``Warning``: A warning, which didn't stop the compilation, but should be addressed if possible. +15. ``Info``: Information that the compiler thinks the user might find useful, but is not dangerous and does not necessarily need to be addressed. +>>>>>>> v0.8.17 .. _compiler-tools: diff --git a/docs/yul.rst b/docs/yul.rst index 0f8003f1a..72c34cf3b 100644 --- a/docs/yul.rst +++ b/docs/yul.rst @@ -1169,6 +1169,7 @@ Yukarıda ``Block``, önceki bölümde Yul kodu dilbilgisinde açıklanan ``Bloc code { function allocate(size) -> ptr { ptr := mload(0x40) + // Note that Solidity generated IR code reserves memory offset ``0x60`` as well, but a pure Yul object is free to use memory as it chooses. if iszero(ptr) { ptr := 0x60 } mstore(0x40, add(ptr, size)) } @@ -1198,6 +1199,7 @@ Yukarıda ``Block``, önceki bölümde Yul kodu dilbilgisinde açıklanan ``Bloc code { function allocate(size) -> ptr { ptr := mload(0x40) + // Note that Solidity generated IR code reserves memory offset ``0x60`` as well, but a pure Yul object is free to use memory as it chooses. if iszero(ptr) { ptr := 0x60 } mstore(0x40, add(ptr, size)) }