Report typos, broken links and other trivial issues here

[cameel]

Description

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

• Typos wording tweaks, bad punctuation and minor grammar issues in variable names, comments, file names, documentation, error messages, 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.

[nikola-matic]

#16022

[cameel]

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]

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

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

[nikola-matic]

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

[baiwfg2]

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.

[Shriever]

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()`.

[cameel]

@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.

[rokk1t]

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

[smitrajput]

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.