Non-interactive mode for yulopti.

[ekpyron]

Background: make it possible to easily run isolated optimizer steps to aid in developing automated verification tools.

Not sure how much we want to refine this, the PR is just a quickly written version that seems to work.

[ekpyron]

Ah, sigh, I mainly wanted to have something quickly to be able to get back to people who would need this :-).
But I guess I can refactor OptimiserSuite (e.g. runSequence currently is public, but the constructor is private, so there's still no way to run it, etc.) and do this properly in the process...

[cameel]

Oh, true, forgot that it's not public. Still, runSequence() can pretty easily be made into a static function and made public. The only state it needs are really m_context and m_debug used by the other overload. It's just a matter of passing these via parameters.

It's not a huge change and I think that not having two separate pieces of code executing these sequences is worth it. And people might want the ability to run bracketed and nested sequences anyway (we do have them in our default sequence after all).

[ekpyron]

Happier now :-)? We could spend a week to make this nicer, but I'd really just like to have anything working fast ;-).

[cameel]

Looks good.

I have some suggestions about stdin handling and exceptions but I'd only consider the ones about exceptions to be important (and I provided suggestions for them that you can just commit and squash) so in the interest of getting it through quickly, I'm approving already.

[cameel]

Just a question: I just noticed that we have it hard-coded. Isn't this parameter kinda important when playing with the optimizer? Maybe we should have a prameter for this (not in this PR of course)?

[ekpyron]

Yep, when I stumbled across this now, I also thought, it should probably be configurable - it would be a bit annoying to do in interactive mode (i.e. allow changing it between steps on the fly), but at least a command line option might be nice. But yeah, we can do it separately.

[cameel]

It's a good easy task for an external contributor. I'll create an issue.

[ekpyron]

Updated. I also noticed that most parser errors are fatal and throw, so to properly report that, we need to catch in parse, too (and the exception does not provide useful info, but it rather remains in the error list).

It also doesn't ignore --help anymore now and has proper exit codes on usage errors and more similar minor changes.

[cameel]

Again, I have some change suggestions but none of it is critical so I'm approving in case you just want to merge it as is.

[ekpyron]

Ok, I globalized the exception handling and while doing so eliminated some status returns :-).

[ekpyron]

Rebased in hopes of it fixing an hopefully random download error in external tests.

[cameel]

Was it a download error or a test error? #12187 was merged today so we will start getting errors if the upstream of these tests has breakage in its main branch. At least for OZ and ENS (and Gnosis after the respective PR gets merged).

[ekpyron]

Was it a download error or a test error? #12187 was merged today so we will start getting errors if the upstream of these tests has breakage in its main branch. At least for OZ and ENS (and Gnosis after the respective PR gets merged).

I didn't pay that much attention and don't see the run anymore... I think it was one of the t_ems_*_ext_zeppelin runs and it complained about not being able to fetch some 0.6 soljson.js (whyever it would want to do that)

[cameel]

t_ems_compile_ext_zeppelin. It does seem like a download failure:

Error BDLR503: Couldn't download compiler version 0.6.12. Checksum verification failed. Please check your connection or use local version 0.6.8

The fact that it tries to download the compiler is probably due to #10745 - it builds with hardhat but we only configure truffle. #12192 fixes that for good but restarting the test seems to have helped here.