♻️ add solc 0.8.18 support

[pcaversaccio]

Description

Add support for solc 0.8.18. The content was generated using $ ./nix/make-solc-static.sh.

Checklist

• tested locally
• added automated tests
• updated the docs
• updated the changelog

Cc: @d-xo

[pcaversaccio]

I discovered today a problem that the Solidity version 0.8.18 binaries were built with a too recent version of GLIBC and thereby did not run on older Linux systems. The binary was rebuilt and now has another hash than the original binary. For more information, see here ethereum/solidity#13921. I will have to update the file accordingly.

[pcaversaccio]

So as summary:

/// Old Solidity 0.8.18 binary version
sha256 = "1g9jbh4xkg4yvyyzyr429xx7spg01qmzdv0rczsjcb28nhzg7h51"

/// New Solidity 0.8.18 binary version
sha256 = "0xxa907llrryrsm9nppfc0lds0l3zfhwngj4zfddhfm6954yvrlm"

This change is reflected via b188f7d.

[cameel]

How are these hashes calculated? Both look different from what sha256sum gives me:

old: a1c0f33eb4482c26f56719ecf62b0ee05d7d7a4f8264ffbddf9ebcd9095c32bd
new: 95e6ed4949a63ad89afb443ecba1fb8302dd2860ee5e9baace3e674a0f48aa77

[cameel]

Is this just a base64 encoding while the CLI tool uses hex? Or are they actually different?

[pcaversaccio]

Is this just a base64 encoding while the CLI tool uses hex? Or are they actually different?

Run it like that:

nix-prefetch-url --type sha256 https://binaries.soliditylang.org/linux-amd64/solc-linux-amd64-v0.8.18+commit.87f61d96

See here.

[cameel]

Ah, ok. I thought that by ethereum/solidity#13921 (comment) you meant that still fails because of checksums but I guess checksums are ok now?

In the log I see failure on this:

Running todo_sig_fuzz... PENDING
parse error: Invalid numeric literal at line 1, column 7
Running test_4byte... FAILURE
 expected [transfer(address,uint256)] but was []
tests.sh:591:test_4byte()

The test looks like this:

dapptools/src/dapp-tests/integration/tests.sh

Lines 588 to 592 in b487610

	# SETH 4BYTE TESTS
	# seth 4byte
	test_4byte() {
	assert_equals "transfer(address,uint256)" "$(seth 4byte a9059cbb | tail -n 1)"
	}

Can't say much because it goes through seth. Is seth 4byte using the compiler under the hood? If not, the problem must be caused by something else.

[pcaversaccio]

checksums are ok yes so nothing to be done on your end imho. It was just weird that when I committed the first version of the compiler, the tests were successful and when I adjusted the checksum to reflect the new binary it failed. So maybe there is indeed a problem in seth...

[cameel]

ok. Let me know if it ends up being something in the compiler after all though. Could always be something that was just not discovered until now and only surfaced in some non-completely deterministic case.

[pcaversaccio]

sure will do - but interestingly the CI also fails for macos so high probability it's not related to the recent Linux build fix.

[pcaversaccio]

@cameel as a heads-up it was an internal connection issue and the CI runs pass now as intended. No issue on the compiler side.

[cameel]

ok, good :) Thanks for the info.

[d-xo]

Thanks!