solidity icon indicating copy to clipboard operation
solidity copied to clipboard

Report typos, broken links and other trivial issues here

Open cameel opened this issue 10 months ago • 15 comments

Description

Please comment in this thread if you want to report trivial issues you find in the repository. This includes:

  • Typos and minor grammar issues in variable names, comments, file names, documentation, etc.
  • Broken links
  • Trivial refactors such as removing dead/unused code, unused imports, redundant else blocks, etc.

Our policy from now on will be to close individual PRs addressing such issues. Instead the team will from time to time look at this thread and fix anything that was reported in bulk.

Motivation

For a while now we've been receiving a lot of trivial pull requests that, while well-intentioned, are very distracting and take more effort to review and merge on an ongoing basis than doing it all at once, in bulk. Especially when they are not ready to be merged as is, but require some back and forth and corrections.

While these trivial imperfections are annoying and we do want them fixed, we don't think doing that with individual small PRs is a good way to go about it. This issue is an attempt to establish a more viable workflow around this.

cameel avatar Jun 18 '25 12:06 cameel

https://github.com/ethereum/solidity/pull/16022

nikola-matic avatar Jun 18 '25 13:06 nikola-matic

3 typos in file names from #15873 that ended up closed without being merged:

  • modifer_recursive.sol -> modifier_recursive.sol
  • no_target_for_abstract_constract.sol -> no_target_for_abstract_contract.sol
  • 142_inheritence_suggestions.sol -> 142_inheritance_suggestions.sol

cameel avatar Jun 18 '25 13:06 cameel

And a botched search&replace in LanguageServer.cpp (#15758):

  • tokenTypes.emplace_back("std::string"); -> tokenTypes.emplace_back("string");

cameel avatar Jun 18 '25 13:06 cameel

Change wording in introduction-to-smart-contracts.rst on line 231 from: (#15974)

enough coins to send, the ``if`` condition evaluates to true. As a result, the ``revert`` will cause the operation to fail

to

enough coins to send, the ``require`` condition evaluates to false. As a result, the ``require`` will cause the operation to fail

nikola-matic avatar Jun 19 '25 10:06 nikola-matic

Found one error in docs.

contract C {
    uint[][] s;

    function f() public {
        // Stores a pointer to the last array element of s.
        uint[] storage ptr = s[s.length - 1];

The function f in contract C cannot run, since array s isn't allocated. I think we should add something like s = new [][](3) at the beginning of f. But I don't know why docs script fails to find this error.

baiwfg2 avatar Jul 02 '25 06:07 baiwfg2

I found a typo in the "Simple Open Auction" example.

// msg.sender is not of types `address payable` and must be
// explicitly converted using `payable(msg.sender)` in order
// use the member function `send()`.

Should be

// msg.sender is not of types `address payable` and must be
// explicitly converted using `payable(msg.sender)` in order
// to use the member function `send()`.

Shriever avatar Jul 04 '25 00:07 Shriever

@baiwfg2 Thanks, it indeed needs a correction.

The function f in contract C cannot run, since array s isn't allocated. I think we should add something like s = new [][](3) at the beginning of f.

Arrays in storage are not explicitly allocated. They are represented with a slot that stores length and whose address uniquely determines the address at which array items are stored. This code will compile just fine.

But you are right that the code is buggy. Or at least incomplete. A call to f() will always revert, because the length is zero and the subtraction will underflow. The array has to be initialized to have at least one element. You could do it in f(), because losing the content does not matter in this example, but the initializer of s would be a more logical place to initialize it.

I think this does not detract much from the goal of the example - to show what happens with dangling elements - but it would indeed be nice to make it fully correct.

But I don't know why docs script fails to find this error.

Because we only check them against compilation errors and it does compile. The revert will happen at runtime.

cameel avatar Jul 14 '25 17:07 cameel

  • https://github.com/ethereum/solidity/blob/develop/docs/units-and-global-variables.rst#block-and-transaction-properties
  • Line 76: blockNumber $\neq$ blocknumber.
  • Line 85: "_ )" $\to$ "_)": extra space.

rokk1t avatar Jul 28 '25 06:07 rokk1t

in the Non-standard Packed Mode section of Contract ABI Specification, it would be cleaner to change

• 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).

to

• 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, as part of strict encoding).

Because otherwise, it seems to be slightly contradicting this statement few lines above: Furthermore, structs as well as nested arrays are not supported.

smitrajput avatar Sep 18 '25 11:09 smitrajput

A duplicate word in Mutations.h: perform perform -> perform. (https://github.com/argotorg/solidity/pull/16282)

clonker avatar Nov 07 '25 12:11 clonker

Duplicate include directive https://github.com/argotorg/solidity/pull/16311

nikola-matic avatar Dec 08 '25 10:12 nikola-matic

Redundant else statements https://github.com/argotorg/solidity/pull/16299

nikola-matic avatar Dec 08 '25 10:12 nikola-matic

Redundant include https://github.com/argotorg/solidity/pull/16288

nikola-matic avatar Dec 08 '25 10:12 nikola-matic

Redundant process import in bytecodecomapre/prepare_report.js https://github.com/argotorg/solidity/pull/16281

nikola-matic avatar Dec 08 '25 10:12 nikola-matic

Redundant ternary in SMTEncoder.cpp https://github.com/argotorg/solidity/pull/16284

nikola-matic avatar Dec 08 '25 11:12 nikola-matic