Remove warnings in examples

[mcdee]

Solidity has moved on since many of the examples in the documentation were written. This causes problems where users cut and paste the examples in to Remix and it spits out what they see as errors (generally warnings but very confusing for new users).

This PR fixes up the various code samples in the documentation so that they don't give spurious examples when pasted in to the current Remix.

Note that this does not update the Solidity version in the relevant pragmas; this could be done in a new PR if required.

[chriseth]

Can you keep the currentOwner variable and just comment out its name?

[mcdee]

I put currentOwner back and updated the function isTokenTransferOK() to use it and avoid the unused variable warning.

[chriseth]

Wonderful, thanks a lot for the many changes! I think you added a public in the wrong place, though:

/tmp/tmp.p9q24UFvAb/test_6a791f1eda2b7fffa811713b141d75572bfde6424d2ebef83d7981a5dc7b11db.sol:4:45: Error: Expected token LBrace got 'Public'

        function f(uint x) returns (uint r) public {

                                            ^

[mcdee]

Good spot; the rogue publics should be in the correct place now.

[axic]

@mcdee great work!

Would it be possible to split this into two PRs?

• public/view/pure`
• shadowing changes

The first one should be fairly simple, but it will also bump the version requirement to 0.4.16 (all the experimental pragmas in the affected sources must be changed). Apart from that this PR should be easy to review and merge.

The second PR with the shadowing changes (renaming variables, function names, contract names) might take a bit more work and back and forth discussion.

[axic]

To clarify: view and pure keywords are only supported starting 0.4.16.

[mcdee]

@axic I've reverted the shadowing changes and bumped the Solidity version where appropriate. I'll create a new PR for the shadowing changes once this one is out of the way.

[axic]

@mcdee great, thank you!

Sorry for this, but three changes have been merged since: #3218, #3197 and #3228. Can you please rebase and check if those two need the visibility & mutability modifiers?

[mcdee]

Rebase should be done and newer code tweaked.

BTW when I was looking at the merges it looks like https://github.com/ethereum/solidity/blob/develop/docs/abi-spec.rst#json is now incorrect. The displayed ABI does not include the definition for g()

[axic]

BTW when I was looking at the merges it looks like https://github.com/ethereum/solidity/blob/develop/docs/abi-spec.rst#json is now incorrect.

You are correct. I've noticed that last week, but then forgot to fix it before merging. Will fix it, unless you are interested pushing a change?

[mcdee]

My ABI contains a whole bunch of additional stuff (payable, stateMutability etc.) and I don't know if you're after any particular order in the JSON so I'll pass on pushing that one.

[axic]

Ok!

Seems like you didn't do a rebase. It should be git rebase develop and that removes all the merge commits from above.

[mcdee]

rebase hates me, always has. I'll take a look.

[axic]

I think you have difficulties because you did not create a separate branch locally. The way to work this around for now is the following:

• git remote add upstream https://github.com/ethereum/solidity
• git fetch upstream
• git rebase upstream/develop

[mcdee]

Did I mention how much rebase hates me? If I every try to rebase on a branch that has upstream changes it wants to do a merge instead.

Some git surgery later, this should now be a PR against current develop with the relevant changes.

[axic]

Please see the logs, there's at least one compilation failure:

/tmp/tmp.FTatqkl4gH/test_6a79c0501150615878f6a7b1bca2aa6e5f937af8a849388990328c5748f9a76f.sol:4:13: Error: Function declared as pure, but this expression (potentially) modifies the state and thus requires non-payable (the default) or payable.
            g([uint(1), 2, 3]);
            ^----------------^

[mcdee]

Apologies for the errors; should be passing now.

[chriseth]

Wonderful, thanks for your hard work, @mcdee !