Introduce experimental flag/option

[nikola-matic]

Under development, don't review yet.

• CLI
• Standard JSON
• Forbid --experimental with --standard-json
• Pragmas
• Docs?
• Changelog

Partially (for now) implements #16123

[github-actions]

This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale label is removed.

[cameel]

Note that there is an issue for this: #16123. Please include it in the description and also check if the PR covers everything.

[cameel]

I wonder if it wouldn't be a good idea to make a prerelease once we merge this PR.

I imagine that this kind of change could cause some disruption for those who were relying on experimental features but shouldn't have.

[cameel]

Should we also mention (as a separate entry) that some features now require the experimental mode (and list those features)? If we do make a prerelease that will be the primary source of information about this.

[nikola-matic]

Yes, we should also notify the solc-tooling group in advance - perhaps even get Lea or whoever has access to our twitter to tweet this out so that tooling is aware.

[cameel]

Let's do that.

[cameel]

I think we have a bug in debugInfo option. The @src annotation is supposed to be present only if "location" is on the list and here it's not (you only included "ethdebug").

[cameel]

You can reduce this to just m_experimental and assert the rest. The analysis is supposed to report an error if any experimental feature is used without m_experimental.

[cameel]

Note also that we have this weird "safe experimental feature" concept here. Apparently it applies to SMTChecker and ABI coder:

solidity/libsolidity/ast/ExperimentalFeatures.h

Lines 39 to 44 in d28d552

	static std::set<ExperimentalFeature> const ExperimentalFeatureWithoutWarning =
	{
	ExperimentalFeature::ABIEncoderV2,
	ExperimentalFeature::SMTChecker,
	ExperimentalFeature::TestOnlyAnalysis,
	};

Oddly, before #7759 which made ABI coder v2 non-experimental, this was instead a list of "analysis-only experimental features". Then it was renamed.

In any case, those happen to be exactly those problematic pragmas that were holding back this PR. Since we were actually going out of our way not to warn about these features, maybe we should just keep the mechanism and exempt from the --experimental flag? Otherwise the mechanism has no use and I'd remove it completely.

[nikola-matic]

You can reduce this to just m_experimental and assert the rest. The analysis is supposed to report an error if any experimental feature is used without m_experimental.

Assert in what way - both m_eofVersion.has_value() and !onlySafeExperimentalFeaturesActivated(...) are just subsets of m_experimental? Asserting every single experimental feature would be a bit of an overkill with the entire OR chain of features.

I'd rather just get rid of it completely.