solhint
solhint copied to clipboard
protofire
Solhint is an open-source project to provide a linting utility for Solidity code.
Without this patch, the path, for example, artifacts/@openzeppelin/contracts/token/ERC20/ERC20.sol/ERC20.dbg.js will be treated as a file artifacts/@openzeppelin/contracts/token/ERC20/ERC20.sol on MacOS system. As a result, npm module fs throws the error: 'Error: EISDIR: illegal...
Without this patch, there are situations when the .solhintignore file causes all inputs files to be ignored. This is a problem because the 'reports' variable ends up being an empty...
Hello, ❌ Error For the next code: ``` // SPDX-License-Identifier: MIT pragma solidity 0.8.10; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; contract BUSD is ERC20 { uint256 public INITIAL_SUPPLY = 100_000_000e18; constructor() ERC20("BUSD", "BUSD") {...
feat/no-console Adding lint rule for banning console.sol and import hardhat/console.sol https://github.com/protofire/solhint/issues/318
Is there a rule for banning `hardhat/console.sol` and usage of `console.log`? I often see developers forgetting to remove these debugging statements when checking in soldity code.
## Description The extend functionality can only extend other packages, not other local solhint configurations. This is not nice when using solhint in a monorepo. ## Reproduction 1. Fork https://github.com/hifi-finance/hifi...
As discussed [here](https://ethereum.stackexchange.com/questions/6795/is-block-timestamp-safe-for-longer-time-periods) and [here](https://ethereum.stackexchange.com/questions/5924/how-do-ethereum-mining-nodes-maintain-a-time-consistent-with-the-network), and shown in practice by many dapps like [Sablier](https://sablier.finance/) which do rely on time, `block.timestamp` is safe to use.
I'm thinking of something similar to [no-inline-assembly](https://github.com/protofire/solhint/blob/3443eee94de7dbda7ad3abd5d3540c3a96e95a0f/docs/rules/security/no-inline-assembly.md), but for custom errors versus revert reason strings. Maybe "no-revert-reason-strings"? [Custom errors](https://blog.soliditylang.org/2021/04/21/custom-errors/) are more elegant and much more gas efficient than revert reason...
This will add support for memory-safe assembly inline blocks: ```diff - assembly { + assembly ("memory-safe") { ``` as per https://docs.soliditylang.org/en/v0.8.13/assembly.html#memory-safety Currently parsing errors due to the outdated version: ```...
Just to get the discussion rolling, I was wondering if it might make sense to conform to some of ESLint's CLI and options given how this project uses a lot...
