Add support for Solidity 0.6 features about sublimeethereum HOT 17 CLOSED

Hi @nventuro ! Sorry for delay, I plan to tackle this shortly ...

from sublimeethereum.

Thank you!

So I think for now it's good enough? (I still have to update the GitHub fork of the highlighter)...

In SublimeText I see:

from sublimeethereum.

Sorry! I have to get (back to) following Solidity some more.. :)

Hopefully this fixes it:

55f492b

Let me know if something is still off !

from sublimeethereum.

Hi @nventuro ! Thank you for the report, always helpful ...

The main issue now is to see how syntax highlighting could be versioned and take into account the version pragma directive...

Or if this is too cumbersome what would you suggest as a solidity developer "in the loop"? Just go with latest version and break the old contracts syntax highlighting? Thank you for any advice here as well...

from sublimeethereum.

Hm, I suspect there'll be overlap of 0.5 and 0.6 for some time, at least a couple months. I see two possible paths forward:

1. the 'right' thing to do would be to parse the pragma directive and choose which syntax to use, but I'm not sure how easy it'd be to add this given the plugin's architecture. Note that there are some edge cases: it is possible to write contracts with pragmas that'll accept both major versions of the compiler, in which case the best thing would probably be to default to the 'old' 0.5 style.
2. add support for 0.6 and be done with it. 0.6's syntax is a superset of 0.5's in many ways: the main non-backwards-compatible changes are the new keywords, but I doubt there are many old contracts out there that used these as identifiers. In any case, you could work around this by releasing this under 1.2 (or 2.0), and pointing users for which the newer syntax breaks towards the outdated (current) release.

I'd personally go with option 2, I'm not sure the value added is worth the extra complexity, and like I said, 0.6 highlighting on 0.5 code should be fine in 99% of the cases.

Thank you so much for your work on this!

from sublimeethereum.

Hi @nventuro ! Can you find an example of abstract contracts ?

Otherwise I have added the rest, including try-catch ... When https://packagecontrol.io/packages/Ethereum updates to 1.1.25 please test a little bit and let me know if there are any issues.

Fits example at https://solidity.readthedocs.io/en/latest/control-structures.html#try-catch ...

from sublimeethereum.

That's great, thanks!

abstract is simply added before the contract keyword, like here: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20Pausable.sol#L14

from sublimeethereum.

Ok thank you, I thought so but couldn't confirm by quick look.

In v1.1.26 abstract keyword for contracts is added.

The only remaining thing I'm not sure is override -- can you provide a few correct examples with context for this as well in case it currently does not work ok ?

Thank you

from sublimeethereum.

There's only two variants for override: it can be found by itself, like here: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20Pausable.sol#L22

Or it can also list a number of identifiers (contract names) in parenthesis, like here: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/deploy-ready/ERC20MinterPauser.sol#L82

from sublimeethereum.

Another thing:

the new receive and ether keywords replace the old anonymous fallback function

Was that a typo ?

Docs say:

The unnamed function commonly referred to as “fallback function” was split up into a new fallback function that is defined using the fallback keyword and a receive ether function defined using the receive keyword.

So are the keywords actually receive and fallback OR receive and ether?

I think this is then the last thing before closing this issue....

from sublimeethereum.

So are the keywords actually receive and fallback OR receive and ether?

Yes, sorry! I was looking at an old changelog, before the final rename. The actual keywords are receive and fallback.

from sublimeethereum.

It looks like the override(x) syntax broke highlighting on v1.1.26:

from sublimeethereum.

OK yes, I see now... Later today everything will be fixed and I close this ticket..

Thank you again for help and sorry for big delay, had some unexpected big tasks in between.

Looking forward for next report(s) when the time comes!

from sublimeethereum.

https://github.com/davidhq/SublimeEthereum/tree/v1.1.28

from sublimeethereum.

Everything now works great, thank you very much for your work!

from sublimeethereum.

It seems my prior testing was incomplete, I found another instance where the highlighter breaks:

I now realize I may not have been clear about receive and fallback before, which are somewhat odd. Sorry about that! They are function names, but are special in that they don't require the function keyword. They behave exactly like constructor in that sense.

from sublimeethereum.

That did it, thanks!

from sublimeethereum.