Syntax error when using the new constructor syntax

tsauvajon commented 6 years ago

From solidity v0.4.22 onwards, the new syntax for constructors is:

pragma solidity ^0.4.23;
contract MyContract {
    constructor() public {
        // initialize things
    }
}

The previous version using the contract's name is now deprecated:

pragma solidity ^0.4.23;
contract MyContract {
    function MyContract() public {
        // initialize things
    }
}

On VSCode using this extension, I get the following error when using the new syntax: ParserError: Expected identifier, got 'LParen' constructor() public { ^.

When compiling my contracts with solc directly or with truffle I get deprecation warnings when using the old syntax, and the new one works well.

juanfranblanco commented 6 years ago

@tsauvajon that is an issue with the linter https://github.com/duaraghav8/Solium/issues/198. I'll keep this open to update it ASAP as it gets added to solium.

juanfranblanco commented 6 years ago

Better duaraghav8/Solium#197 (typo above)

duaraghav8 commented 6 years ago

v1.1.7 now supports this!

juanfranblanco commented 6 years ago

Thanks @duaraghav8 ill update ASAP.

juanfranblanco commented 6 years ago

It has been upgraded and released now. Please reopen if you see any issues. Thanks again @duaraghav8 !!

jaycenhorton commented 6 years ago

From time to time something is causing this issue to get reintroduced. I am not sure how to reproduce, or what the issue might be. This is a problem, because it prevents it from noticing issues happening later in the file (note the misdeclared uint as a string just below it).

solc-js version Solidity v0.4.24 (solc-js)

jaycenhorton commented 6 years ago

For whatever reason, I am also able to resolve this issue by:

deleting node_modules anywhere they exist in the project
deleting .lock files
restarting vscode

In case it wasn't those steps that resolved this (can't reproduce as I don't know what causes the random reintroduction of this issue), I also did the following which might impact the above steps value
npm uninstall -g truffle
npm install -g solc
npm uninstall -g solc
adding and then removing "solidity.compileUsingRemoteVersion": "latest", in user and workspace settings for .vscode

juanfranblanco commented 6 years ago

solc global will not do anything for vscode
if your node_modules have solc, there might be a conflict there
adding and removing the compile version might have helped to trigger the refresh of the compiler.

jaycenhorton commented 6 years ago

As this just happened once more, I was able to attribute the cause to node_modules, though I'm still not where within it. The issue seems to be introduced quite often when working inside a monorepo with different node_modules per folder.

Is there a way to force this to ignore node_modules? Is that what is done when using solidity.compileUsingRemoteVersion ?

juanfranblanco commented 6 years ago

No the flow goes (as it is a general setting) to override using the local node modules solc. I'll raise another issue to create a setting to ignore manually enable node modules for solc

jaycenhorton commented 6 years ago

tl;dr, run `yarn upgrade`

Ok! Finally able to pinpoint the issue! It was indeed a rogue solc dependency (version 0.4.21) which was an artifact of a long-ago install of that version.

The issue was basically with yarn incorrectly deduping solc when running yarn install, see here

In that, the following existed in my yarn.lock file

solc@0.4.24, solc@^0.4.19:
  version "0.4.24"
  resolved "https://registry.yarnpkg.com/solc/-/solc-0.4.24.tgz#354f14b269b38cbaa82a47d1ff151723502b954e"
  integrity sha512-2xd7Cf1HeVwrIb6Bu1cwY2/TaLRodrppCq3l7rhLimFQgmxptXhTC3+/wesVLpB09F1A2kZgvbMOgH7wvhFnBQ==
  dependencies:
    fs-extra "^0.30.0"
    memorystream "^0.3.1"
    require-from-string "^1.1.0"
    semver "^5.3.0"
    yargs "^4.7.1"

solc@^0.4.2:
  version "0.4.21"
  resolved "https://registry.yarnpkg.com/solc/-/solc-0.4.21.tgz#6a7ecd505bfa0fc268330d5de6b9ae65c8c68264"
  integrity sha512-8lJmimVjOG9AJOQRWS2ph4rSctPMsPGZ4H360HLs5iI+euUlt7iAvUxSLeFZZzwk0kas4Qta7HmlMXNU3yYwhw==
  dependencies:
    fs-extra "^0.30.0"
    memorystream "^0.3.1"
    require-from-string "^1.1.0"
    semver "^5.3.0"
    yargs "^4.7.1"

The side-efffect of such was that yarn was preferring the 0.4.21 version, which predates the constructor syntax.

The solution (simply removing the .lock file and regenerating it is inappropriate due to the nature of how it works). Instead:

yarn upgrade

voila, no more issue!

juanfranblanco / vscode-solidity