Skip to content

Update OZ solhint custom rules#5794

Merged
Amxx merged 22 commits intoOpenZeppelin:masterfrom
gonzaotc:update-solhint-custom-rules
Sep 23, 2025
Merged

Update OZ solhint custom rules#5794
Amxx merged 22 commits intoOpenZeppelin:masterfrom
gonzaotc:update-solhint-custom-rules

Conversation

@gonzaotc
Copy link
Contributor

@gonzaotc gonzaotc commented Jul 10, 2025

  1. Removes interface-names custom rule which is now covered by solhint's already included interface-starts-with-i
  2. Adds interface-only-external-functions rule.
  3. Prevents leading underscore in constants and immutables, which was previously only prevented in private constants
  4. Prevents leading underscore in public and external functions.
  5. Prevents external virtual functions.

Note that 2, 3, and 4 require breaking changes that can be potential candidates for 6.0

Ideally I would like to add another rule to verify that Interfaces can only import other interfaces

@gonzaotc gonzaotc requested a review from a team as a code owner July 10, 2025 20:03
@changeset-bot
Copy link

changeset-bot bot commented Jul 10, 2025

⚠️ No Changeset found

Latest commit: eb66607

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@gonzaotc gonzaotc marked this pull request as draft July 10, 2025 20:03
@Amxx
Copy link
Collaborator

Amxx commented Jul 10, 2025

For reference, there is already this PR that deals with linter rules: #5497

Copy link
Collaborator

@Amxx Amxx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally I would like to add another rule to verify that Interfaces can only import other interfaces

AFAIK, this is already something solidity enforces. We don't need the linter to check taht if the compiler rejects it anyway.

Edit: that is true of "inheritance", importing is a different thing.

Copy link
Collaborator

@Amxx Amxx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How efficient/explicit is /^_/.test(node.name) compared to node.name.startsWith('_')

@Amxx Amxx force-pushed the update-solhint-custom-rules branch from d1b7fad to ca766d7 Compare July 24, 2025 14:51
@Amxx Amxx added automation Tests and coverage running. Docsite publishing. ignore-changeset CI labels Jul 31, 2025
@Amxx Amxx added this to the 5.5 milestone Jul 31, 2025
@Amxx Amxx marked this pull request as ready for review August 27, 2025 13:22
@Amxx Amxx changed the title Update OZ solhint custom rules [WIP] Update OZ solhint custom rules Aug 27, 2025
Copy link
Member

@ernestognw ernestognw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious about the external -> public changes. So far I thought we already made all functions public when needed, so I would assume they were intentional, can we confirm reviewing the history to make sure we're not missing a deliberate decision?

* @custom:oz-upgrades-unsafe-allow-reachable delegatecall
*/
function multicall(bytes[] calldata data) external virtual returns (bytes[] memory results) {
function multicall(bytes[] calldata data) public virtual returns (bytes[] memory results) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remember correctly, this is purposely external since it doesn't have an internal use. Users could just call the functions they want directly

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By default, all public facing functions should be public so that overrides can call super.

If we have exceptions, the questions we need to answer are:

  1. is there any reason we think overrides won't need to call super?
  2. is there any risks in making that internally callable?

I'm not sure what override we would want to do, but I'd say calling super would be reasonnable here ... so really the question that remains is 2.

If function A internally calls multicall(...) (instead of doing this.multicall(...)) that would allow arbitrary function execution with the same caller as A's initial context. That is also what we would achieve by directly calling the corresponding function (assuming they are public and not external).

But yes, let review all the external->public changes, and we can disable the rule selectivelly if we have a good reason to keep the functions externals

@Amxx Amxx requested a review from a team September 19, 2025 08:23
@socket-security
Copy link

socket-security bot commented Sep 19, 2025

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Updatednpm/​solhint@​6.0.0 ⏵ 6.0.19810010089 +370

View full report

@socket-security
Copy link

socket-security bot commented Sep 19, 2025

All alerts resolved. Learn more about Socket for GitHub.

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

View full report

// TODO: expand visibility and fix
if (node.visibility === 'private' && /^_/.test(node.name)) {
this.error(node, 'Constant variables should not have leading underscore');
this.require(!node.name.startsWith('_'), node, 'Constant variables should not have leading underscore');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we require screaming snake case?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is already a const-name-snakecase in solhint. See line 5 of solhint.config.js

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to do immutable snakecase, there is also a immutable-vars-naming we could enable.

arr00
arr00 previously approved these changes Sep 19, 2025
@gonzaotc
Copy link
Contributor Author

Seems like the consensus on immutables is to be more relaxed and leave them as they are (since there are 20+ cases), and I’m fine with that.

The only pending item I see is:

But yes, let’s review all the external → public changes, and disable the rule selectively if we have good reasons to keep some functions external.

@Amxx Amxx merged commit 1078ecb into OpenZeppelin:master Sep 23, 2025
28 of 29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

automation Tests and coverage running. Docsite publishing. CI ignore-changeset

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants