Support experimental feature pragma

[axic]

Implements #2346.

[axic]

This has no tests yet, let us first agree it does everything the way it should:

• pragma must be followed by an identifier (i.e. cannot be any other token), which can be followed by any token
• experimental must be followed by at least one identifier, but multiple are accepted
• duplicates are forbidden

Now when checking for a specific feature, I'd say to check if experimentalFeatures.count(feature) || experimentalFeatures.count('*'). We could add a helper for that on the annotation too: bool enablesExperimentalFeature(key).

[axic]

Possibly also it should issue a warning whenever the pragma is encountered.

[roadriverrail]

I think this is a good start. Right now, it looks like if I typed in a non-existant experimental feature (e.g. "pragma experimental foo"), this would end up being basically a no-op, so we don't really get the benefit of the compiler spotting typos. What if experimental features could register their pragma names, and then if they weren't on the list, the SyntaxChecker could issue an error)?

[axic]

I think to keep it simple just add the supported const list in SyntaxChecker.

[axic]

Also the wildcard will not be able to do much type checking :)

[roadriverrail]

I guess since we currently only have two features, a simple const list in the SyntaxChecker works. No reason to get overly complicated.

[axic]

Also once any of these features (z3, overflow check) graduate from experimental status, we could still keep them optionally turned on by pragma feature z3;

[chriseth]

Depending on the feature, this has to be done much earlier, probably best in the parser.

[chriseth]

Sorry, confused that with SemanticAnalyzer.

[axic]

Agreed, but that requires a few more helpers as the parser doesn't currently maintain what sourceunit it is in.

[axic]

Idea: how about adding an experimental tag into the metadata CBOR if any experimental mode is selected?

Reason: expose that the contract should not be relied on in the bytecode and not only in the metadata JSON, which very linkely will not be uploaded anywhere.

Effect: regular contract validators will just deny because the CBOR looks invalid to them, and those which understand the flag will have to stop because of the flag.

Example:

{bzzr:"<swarmhash>",experimental:true}

[axic]

We've also decided offline to:

• have one pragma experimental per feature
• do not support wildcard
• have an enum for the features
• keep the enum/string mapping in a new header AST/ExperimentalFeatures.h

[axic]

I'd like to split off the metadata stamp changes to a separate PR, because that might require more decision, while this above should be ready.

[axic]

@chriseth do you want to review this after the release? Perhaps we could reduce the number of error messages, it may be too much detail.

[chriseth]

Can you call this g_experimentalFeatureNames or put it inside a class?

[axic]

Updated ExperimentalFeatureNames to start with an uppercase letter as it is a global (similar to Version.h)

[duaraghav8]

@axic slightly confused here. Are multiple identifiers allowed after experimental? If yes, what's the syntax? (Tried comma-separated & space-separated with no luck)

[axic]

No, it was changed to only a single one.