Ethereum

System information

Geth
Version: 1.10.13-stable
Git Commit: 7a0c19f813e285516f4b525305fd73b625d2dec8
Architecture: amd64
Go Version: go1.17.3
Operating System: linux
GOPATH=
GOROOT=go

Expected behaviour

Close files that aren't in use / have a settable limit

Actual behaviour

Every database file it opens stays open for the duration of the sync

Steps to re

OpenZeppelin is currently working on a base-64 library (OpenZeppelin/openzeppelin-contracts#2884) and it turns out that our optimizer is not yet good enough to get to the level of hand-optimized assembly in that case. We should add this code as a test case so that we can use it to evaluate our optimizer improvements.

In the PR and its comments you'll find versions of the

Issue

Vyper handles unmapped instructions differently from Solidity. In Solidity, unmapped instructions are given a file index of -1. When attempting to show the source for such an instruction, we instead just show 1: // No source code found..

However, in Vyper, such instructions are not given a file index of -1, but are given a start and length of 0. So when we show the source for t

A parametrized option to set the blocksize would be useful to experiment with. As quorum is used in a private setting I think this option should be available

Add custom clj-kondo hooks for macroses to ensure that lint rules are followed inside them.

Macros to be handled:

• fx/defn - similarly to defn with check on metadata for ::events
• fx/merge - seems like it could be lint'ed as thread macro, plus warn on limitations
• defview
• letsubs - lint as let + check on types for