Version 2.1.0 throws unhandled error during formatting

[Siegrift]

[error] contracts/<CONTRACT_NAME>: Error: We encountered the following syntax error:
[error]
[error] 	Expected EqualGreaterThan.
[error]
[error] Based on the pragma statements, we inferred your code to be using Solidity version 0.8.17. If you would like to change that, update the pragmas in your source file, or specify a version in your `.prettierrc` file.

My contract starts with the following:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

which seems to be parsed well in other files, so I dunno what actually causes the error. However, everything works fine with with version 2.0.0 (I noticed this issue during dependency upgrade). Unfortunately, I can't share the contract implementation details.

[Janther]

Since version 2.1.0 we rely on Slang's version inference which restricts the range of available versions of solidity we can use to the ones given by the pragma statement. In your case we restricted the available versions to 0.8.17, 0.8.18, 0.8.19, 0.8.20, 0.8.21, 0.8.22, 0.8.23, 0.8.24, 0.8.25, 0.8.26, 0.8.27, 0.8.28, 0.8.29, and 0.8.30. From this list we are trusting the developer is using syntax compatible with the lowest possible version in this case 0.8.17.

From what I can see, in version:

• 0.8.19 the syntax using ... for ... ; was introduced.
• 0.8.22 event declarations at the file level were introduced.
• 0.8.27 the transient keyword was introduced.
• 0.8.29 the storage layout was introduced

Probably during your developing cycle you started developing using version 0.8.17 and as new versions kept being released, you adopted one of the new syntax added in Solidity and upgraded the compiler without updating the pragma statement declaring the solidity versions compatible with the file.

To solve this error you can update the pragma solidity ^0.8.17; statement to better represent the versions of solidity that support the syntax in the file. Or tell prettier-plugin-solidity what compiler you are using to compile your files in the .prettierrc file by declaring the compiler option.

There are many ways to approach version inference and we had many internal conversations around it but not much feedback on how the community would use our plugin. We would appreciate some feedback on the version inference, what would you as a user expect from it, and what error message would guide you better in fixing this error.

[Siegrift]

Some of the contracts we use are external and we use multiple version of the compiler (some contracts mandate a fixed version). Here's how my hardhat.config.ts looks like:

solidity: {
    compilers: [
      {
        version: '0.8.24',
        settings: {
          optimizer: {
            enabled: true,
            runs: 100,
          },
        },
      },
      {
        version: '0.8.20',
        settings: {
          optimizer: {
            enabled: true,
            runs: 200,
          },
        },
      },
      {
        version: '0.8.17',
        settings: {
          optimizer: {
            enabled: true,
            runs: 200,
          },
        },
      },
      {
        version: '0.8.12',
        settings: {
          optimizer: {
            enabled: true,
            runs: 200,
          },
        },
      },
    ],

I could use the compiler settings as outlined here, but it feels clunky to me to maintain this configuration. I'd much rather specify a set of compilers that are to be used for linting (the same way as Hardhat does it).

I've found a somewhat smaller reproducible example. I basically removed all other contracts, and left only this contract (and its dependencies). The output I get when I run the prettier format is:

contracts/external/uniswap/permit2/interfaces/IAllowanceTransfer.sol
[error] contracts/external/uniswap/permit2/interfaces/IAllowanceTransfer.sol: Error: We encountered the following syntax error:
[error]
[error] 	Expected Equal or Semicolon.
[error]
...

I now see that the prettier complains about the use of errors, which are only supported since v0.8.4... I think this will be a rather widespread issue, because people often change their version in HH config and forget to update the pragmas. For me, it's much more convenient to stay on version 2.0.0 rather then sort this out in all of the affected contracts just to have the formatting working.

[fvictorio]

Thanks for the details @Siegrift

Yes, I think the easiest solution is to just use the latest compatible version instead of the earliest. I thought it was a good idea to let people know that their pragmas were wrong, but now I see that it's more annoying than anything else.

The problem with using the latest compatible version is that it's a moving target: you update prettier solidity, get a new version of Slang that supports a new version of Solidity, and suddenly you are using a different parser. But I think 99% of the time this will be fine.

[fvictorio]

@Siegrift I just published prettier-plugin-solidity@2.2.0-rc.0 (from this PR).

Could you install prettier-plugin-solidity@rc and check if it fixes your issue?

[Siegrift]

Mhh, tried that just now and it still appears to format the files using 0.8.0 version 🤔

[fvictorio]

Sorry, my bad, I did a half-assed fix. Can you try again with 2.2.0-rc.1?

[Siegrift]

Indeed that causes no issues for us anymore. I tried it on our full repo with a bunch of external contracts and I got some lint breakages, but no errors.

[OmarTawfik]

so I dunno what actually causes the error.

@fvictorio @Janther I suggest including the line/column in the error message, to make it easier to pinpoint the offending syntax?

prettier-plugin-solidity/src/slang-utils/create-parser.ts

Line 29 in 254cff2

`We encountered the following syntax error:\n\n\t${result.parseOutput.errors()[0].message}\n\n${reason}`

[Siegrift]

@fvictorio Any estimate when the 2.2.0 version will be released?

[Janther]

hi @Siegrift,

I'm waiting for the next slang version that should be coming soon and hopefully some of the performance PR's to be reviewed and included.

[wighawag]

I am hitting the same issue and that's actually cool to have these error somehow (though it will great if it was optional), also for the errors if we could get the exact line, col number that would be great

[fvictorio]

@wighawag you can use Slippy's compatible-pragma rule for that 🙂 https://github.com/fvictorio/slippy/blob/main/docs/rules/compatible-pragma.md

[wighawag]

Thanks @fvictorio , I did not even know about slippy :)