sync master<>dev #2341

0xalpharush · 2024-02-29T17:58:36Z

No description provided.

Bumps [actions/setup-node](https://github.com/actions/setup-node) from 3 to 4. - [Release notes](https://github.com/actions/setup-node/releases) - [Commits](actions/setup-node@v3...v4) --- updated-dependencies: - dependency-name: actions/setup-node dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>

removed trailing whitespace

Update README.md

Update installation instrucitons

Update Dockerfile

…tions/setup-node-4 Bump actions/setup-node from 3 to 4

…y this just silently exited

Raise an error when a missing contract is specified to read-storage

Bumps [cachix/install-nix-action](https://github.com/cachix/install-nix-action) from 23 to 24. - [Release notes](https://github.com/cachix/install-nix-action/releases) - [Commits](cachix/install-nix-action@v23...v24) --- updated-dependencies: - dependency-name: cachix/install-nix-action dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>

Bumps [actions/configure-pages](https://github.com/actions/configure-pages) from 3 to 4. - [Release notes](https://github.com/actions/configure-pages/releases) - [Commits](actions/configure-pages@v3...v4) --- updated-dependencies: - dependency-name: actions/configure-pages dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>

Bumps [actions/deploy-pages](https://github.com/actions/deploy-pages) from 2 to 3. - [Release notes](https://github.com/actions/deploy-pages/releases) - [Commits](actions/deploy-pages@v2...v3) --- updated-dependencies: - dependency-name: actions/deploy-pages dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>

Bumps [pypa/gh-action-pypi-publish](https://github.com/pypa/gh-action-pypi-publish) from 1.8.10 to 1.8.11. - [Release notes](https://github.com/pypa/gh-action-pypi-publish/releases) - [Commits](pypa/gh-action-pypi-publish@v1.8.10...v1.8.11) --- updated-dependencies: - dependency-name: pypa/gh-action-pypi-publish dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>

…chix/install-nix-action-24 Bump cachix/install-nix-action from 23 to 24

…tions/configure-pages-4 Bump actions/configure-pages from 3 to 4

…tions/deploy-pages-3 Bump actions/deploy-pages from 2 to 3

…pa/gh-action-pypi-publish-1.8.11 Bump pypa/gh-action-pypi-publish from 1.8.10 to 1.8.11

remove unused files

fix is_reentrant for internal vyper functions

Substituted the letter `z` with `x` in pre-declaration

Create a variable API that filters out constants and immutables

add regression test for #2313

Add support Solidity 0.8.24

fix: support renaming in base inheritance and base constructor calls

msg-value-loop: Don't report if msg.value is in a conditional expression

incorrect-shift: Detect only assembly blocks

Bumps [docker/metadata-action](https://github.com/docker/metadata-action) from 4 to 5. - [Release notes](https://github.com/docker/metadata-action/releases) - [Upgrade guide](https://github.com/docker/metadata-action/blob/master/UPGRADE.md) - [Commits](docker/metadata-action@v4...v5) --- updated-dependencies: - dependency-name: docker/metadata-action dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>

…cker/metadata-action-5 Bump docker/metadata-action from 4 to 5

…ate-names fix: support inheritance resolution when contract name is reused

…ctor Feat/out of order retryable detector

Track storage variables read/written in assembly

Add --include-paths option

coderabbitai · 2024-02-29T17:59:08Z

Walkthrough

The recent updates encompass enhancements across GitHub Actions, Docker configurations, and the project's core functionalities. Notably, there's a shift towards using the latest versions of essential tools and actions, improvements in handling Solidity and Vyper code, and the introduction of new detectors and mutators. These changes aim to refine the development workflow, extend compatibility, and bolster the detection capabilities for smart contract vulnerabilities.

Changes

Files	Change Summary
`.github/actions/upload-coverage/action.yml`	Updated `actions/upload-artifact` to `v4`; modified `name` parameter.
`.github/workflows/...` (multiple)	Updated `setup-python` to `v5`; newer versions for actions used.
`Dockerfile`	Use `solc-select use latest` instead of specific version installation.
`README.md`	Added Vyper support; updated `slither-analyzer` commands and documentation links.
`examples/scripts/...` (`data_dependency.py`, `data_dependency.sol`, `possible_paths.py`)	Added `SimpleModifier` contract and interactions; modified list comprehension.
`slither/...` (multiple core files)	Updates and additions for Solidity and Vyper support, improved parsing, and new functionalities.
`tests/e2e/...` (multiple test files and directories)	Updated and added test data, assertions, and a new test case for `OutOfOrderRetryable`.

Poem

In the garden of code, where the smart contracts bloom,
A rabbit hopped in, avoiding the gloom.
With updates and patches, it danced through the night,
Enhancing the scripts, making them tight.
🌟 "To the latest, we go!" it cheerfully sings,
As it hops through the code, fixing all things.
With each line it mends, the garden shines bright,
A testament to the rabbit's diligent plight.

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>.
- Generate unit-tests for this file.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai generate unit tests for this file.
- @coderabbitai modularize this function.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai generate interesting stats about this repository from git and render them as a table.
- @coderabbitai show all the console.log statements in this repository.
- @coderabbitai read src/utils.ts and generate unit tests.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (`.coderabbit.yaml`)

You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
The JSON schema for the configuration file is available here.
If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

coderabbitai

Review Status

Actionable comments generated: 15

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between e3dcf1e and a8dc50e.

Files ignored due to path filters (193)

tests/e2e/detectors/test_data/constable-states/0.8.0/const_state_variables.sol-0.8.0.zip is excluded by: !**/*.zip
tests/e2e/detectors/test_data/incorrect-shift/0.4.25/shift_parameter_mixup.sol-0.4.25.zip is excluded by: !**/*.zip
tests/e2e/detectors/test_data/incorrect-shift/0.5.16/shift_parameter_mixup.sol-0.5.16.zip is excluded by: !**/*.zip
tests/e2e/detectors/test_data/incorrect-shift/0.6.11/shift_parameter_mixup.sol-0.6.11.zip is excluded by: !**/*.zip
tests/e2e/detectors/test_data/incorrect-shift/0.7.6/shift_parameter_mixup.sol-0.7.6.zip is excluded by: !**/*.zip
tests/e2e/detectors/test_data/msg-value-loop/0.4.25/msg_value_loop.sol-0.4.25.zip is excluded by: !**/*.zip
tests/e2e/detectors/test_data/msg-value-loop/0.5.16/msg_value_loop.sol-0.5.16.zip is excluded by: !**/*.zip
tests/e2e/detectors/test_data/msg-value-loop/0.6.11/msg_value_loop.sol-0.6.11.zip is excluded by: !**/*.zip
tests/e2e/detectors/test_data/msg-value-loop/0.7.6/msg_value_loop.sol-0.7.6.zip is excluded by: !**/*.zip
tests/e2e/detectors/test_data/msg-value-loop/0.8.0/msg_value_loop.sol-0.8.0.zip is excluded by: !**/*.zip
tests/e2e/detectors/test_data/out-of-order-retryable/0.8.20/out_of_order_retryable.sol-0.8.20.zip is excluded by: !**/*.zip
tests/e2e/detectors/test_data/suicidal/0.7.6/suicidal.sol-0.7.6.zip is excluded by: !**/*.zip
tests/e2e/solc_parsing/test_data/compile/event-top-level.sol-0.8.22-compact.zip is excluded by: !**/*.zip
tests/e2e/solc_parsing/test_data/compile/solidity-0.8.24.sol-0.8.24-compact.zip is excluded by: !**/*.zip
tests/e2e/solc_parsing/test_data/compile/using-for-this-contract.sol-0.8.15-compact.zip is excluded by: !**/*.zip
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.0-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.1-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.10-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.11-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.12-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.12-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.13-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.13-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.14-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.14-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.15-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.15-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.16-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.16-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.17-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.17-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.18-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.18-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.19-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.19-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.2-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.20-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.20-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.21-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.21-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.22-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.22-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.23-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.23-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.24-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.24-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.25-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.25-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.26-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.26-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.3-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.4-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.5-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.6-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.7-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.8-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.4.9-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.0-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.0-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.1-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.1-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.10-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.10-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.11-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.11-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.12-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.12-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.13-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.13-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.14-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.14-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.15-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.15-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.16-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.16-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.17-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.17-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.2-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.2-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.3-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.3-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.4-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.4-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.5-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.5-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.6-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.6-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.7-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.7-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.8-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.8-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.9-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.5.9-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.6.0-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.6.1-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.6.10-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.6.11-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.6.12-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.6.2-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.6.3-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.6.4-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.6.5-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.6.6-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.6.7-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.6.8-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.6.9-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.7.0-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.7.1-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.7.2-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.7.3-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.7.4-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.7.5-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-all.sol-0.7.6-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-functions.sol-0.6.9-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/assembly-functions.sol-0.7.6-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/event-top-level.sol-0.8.22-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/solidity-0.8.24.sol-0.8.24-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/using-for-this-contract.sol-0.8.15-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.0.sol-0.4.0-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.1.sol-0.4.1-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.1.sol-0.4.10-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.1.sol-0.4.2-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.1.sol-0.4.3-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.1.sol-0.4.4-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.1.sol-0.4.5-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.1.sol-0.4.6-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.1.sol-0.4.7-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.1.sol-0.4.8-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.1.sol-0.4.9-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.11-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.12-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.12-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.13-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.13-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.14-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.14-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.15-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.15-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.16-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.16-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.17-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.17-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.18-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.18-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.19-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.19-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.20-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.20-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.21-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.21-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.22-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.22-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.23-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.23-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.24-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.24-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.25-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.25-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.26-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.4.26-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.0-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.0-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.1-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.1-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.10-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.10-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.11-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.11-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.12-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.12-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.13-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.13-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.14-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.14-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.15-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.15-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.16-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.16-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.17-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.17-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.2-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.2-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.3-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.3-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.4-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.4-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.5-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.5-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.6-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.6-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.7-compact.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.7-legacy.json is excluded by: !**/*.json
tests/e2e/solc_parsing/test_data/expected/yul-0.4.11.sol-0.5.8-compact.json is excluded by: !**/*.json

Files selected for processing (104)

.github/actions/upload-coverage/action.yml (1 hunks)
.github/workflows/black.yml (1 hunks)
.github/workflows/ci.yml (2 hunks)
.github/workflows/docker.yml (1 hunks)
.github/workflows/docs.yml (1 hunks)
.github/workflows/doctor.yml (1 hunks)
.github/workflows/linter.yml (1 hunks)
.github/workflows/pip-audit.yml (1 hunks)
.github/workflows/publish.yml (3 hunks)
.github/workflows/pylint.yml (1 hunks)
.github/workflows/test.yml (3 hunks)
Dockerfile (1 hunks)
README.md (4 hunks)
examples/scripts/data_dependency.py (1 hunks)
examples/scripts/data_dependency.sol (1 hunks)
examples/scripts/possible_paths.py (1 hunks)
slither/main.py (5 hunks)
slither/core/cfg/node.py (2 hunks)
slither/core/compilation_unit.py (4 hunks)
slither/core/declarations/init.py (1 hunks)
slither/core/declarations/contract.py (4 hunks)
slither/core/declarations/event.py (2 hunks)
slither/core/declarations/event_contract.py (1 hunks)
slither/core/declarations/event_top_level.py (1 hunks)
slither/core/declarations/function.py (2 hunks)
slither/core/declarations/solidity_variables.py (2 hunks)
slither/core/scope/scope.py (4 hunks)
slither/core/slither_core.py (4 hunks)
slither/core/variables/variable.py (1 hunks)
slither/detectors/all_detectors.py (1 hunks)
slither/detectors/assembly/incorrect_return.py (1 hunks)
slither/detectors/assembly/return_instead_of_leave.py (1 hunks)
slither/detectors/assembly/shift_parameter_mixup.py (2 hunks)
slither/detectors/functions/out_of_order_retryable.py (1 hunks)
slither/detectors/functions/suicidal.py (1 hunks)
slither/detectors/statements/divide_before_multiply.py (1 hunks)
slither/detectors/statements/msg_value_in_loop.py (2 hunks)
slither/detectors/variables/predeclaration_usage_local.py (1 hunks)
slither/detectors/variables/unchanged_state_variables.py (2 hunks)
slither/printers/summary/variable_order.py (1 hunks)
slither/slither.py (1 hunks)
slither/slithir/convert.py (2 hunks)
slither/solc_parsing/declarations/contract.py (2 hunks)
slither/solc_parsing/declarations/event.py (2 hunks)
slither/solc_parsing/declarations/function.py (2 hunks)
slither/solc_parsing/declarations/modifier.py (1 hunks)
slither/solc_parsing/expressions/find_variable.py (1 hunks)
slither/solc_parsing/slither_compilation_unit_solc.py (4 hunks)
slither/solc_parsing/yul/evm_functions.py (5 hunks)
slither/tools/documentation/main.py (1 hunks)
slither/tools/flattening/flattening.py (1 hunks)
slither/tools/mutator/README.md (1 hunks)
slither/tools/mutator/main.py (5 hunks)
slither/tools/mutator/mutators/AOR.py (1 hunks)
slither/tools/mutator/mutators/ASOR.py (1 hunks)
slither/tools/mutator/mutators/BOR.py (1 hunks)
slither/tools/mutator/mutators/CR.py (1 hunks)
slither/tools/mutator/mutators/FHR.py (1 hunks)
slither/tools/mutator/mutators/LIR.py (1 hunks)
slither/tools/mutator/mutators/LOR.py (1 hunks)
slither/tools/mutator/mutators/MIA.py (1 hunks)
slither/tools/mutator/mutators/MVIE.py (1 hunks)
slither/tools/mutator/mutators/MVIV.py (1 hunks)
slither/tools/mutator/mutators/MWA.py (1 hunks)
slither/tools/mutator/mutators/ROR.py (1 hunks)
slither/tools/mutator/mutators/RR.py (1 hunks)
slither/tools/mutator/mutators/SBR.py (1 hunks)
slither/tools/mutator/mutators/UOR.py (1 hunks)
slither/tools/mutator/mutators/abstract_mutator.py (3 hunks)
slither/tools/mutator/mutators/all_mutators.py (1 hunks)
slither/tools/mutator/utils/command_line.py (2 hunks)
slither/tools/mutator/utils/file_handling.py (1 hunks)
slither/tools/mutator/utils/patch.py (1 hunks)
slither/tools/mutator/utils/testing_generated_mutant.py (1 hunks)
slither/tools/properties/main.py (1 hunks)
slither/tools/read_storage/main.py (2 hunks)
slither/tools/read_storage/read_storage.py (1 hunks)
slither/tools/upgradeability/checks/variable_initialization.py (1 hunks)
slither/tools/upgradeability/checks/variables_order.py (2 hunks)
slither/utils/command_line.py (2 hunks)
slither/utils/encoding.py (1 hunks)
slither/utils/myprettytable.py (2 hunks)
slither/utils/upgradeability.py (4 hunks)
slither/vyper_parsing/declarations/contract.py (2 hunks)
tests/e2e/compilation/test_resolution.py (1 hunks)
tests/e2e/detectors/snapshots/detectors__detector_OutOfOrderRetryable_0_8_20_out_of_order_retryable_sol__0.txt (1 hunks)
tests/e2e/detectors/snapshots/detectors__detector_ShiftParameterMixup_0_6_11_shift_parameter_mixup_sol__0.txt (1 hunks)
tests/e2e/detectors/snapshots/detectors__detector_ShiftParameterMixup_0_7_6_shift_parameter_mixup_sol__0.txt (1 hunks)
tests/e2e/detectors/snapshots/detectors__detector_Suicidal_0_7_6_suicidal_sol__0.txt (1 hunks)
tests/e2e/detectors/test_data/constable-states/0.8.0/const_state_variables.sol (1 hunks)
tests/e2e/detectors/test_data/incorrect-shift/0.4.25/shift_parameter_mixup.sol (1 hunks)
tests/e2e/detectors/test_data/incorrect-shift/0.5.16/shift_parameter_mixup.sol (1 hunks)
tests/e2e/detectors/test_data/incorrect-shift/0.6.11/shift_parameter_mixup.sol (1 hunks)
tests/e2e/detectors/test_data/incorrect-shift/0.7.6/shift_parameter_mixup.sol (1 hunks)
tests/e2e/detectors/test_data/msg-value-loop/0.4.25/msg_value_loop.sol (1 hunks)
tests/e2e/detectors/test_data/msg-value-loop/0.5.16/msg_value_loop.sol (1 hunks)
tests/e2e/detectors/test_data/msg-value-loop/0.6.11/msg_value_loop.sol (1 hunks)
tests/e2e/detectors/test_data/msg-value-loop/0.7.6/msg_value_loop.sol (1 hunks)
tests/e2e/detectors/test_data/msg-value-loop/0.8.0/msg_value_loop.sol (1 hunks)
tests/e2e/detectors/test_data/out-of-order-retryable/0.8.20/out_of_order_retryable.sol (1 hunks)
tests/e2e/detectors/test_data/suicidal/0.7.6/suicidal.sol (1 hunks)
tests/e2e/detectors/test_detectors.py (1 hunks)
tests/e2e/solc_parsing/test_ast_parsing.py (8 hunks)
tests/e2e/solc_parsing/test_data/event-top-level.sol (1 hunks)

Files skipped from review due to trivial changes (3)

slither/detectors/all_detectors.py
slither/detectors/assembly/incorrect_return.py
slither/detectors/assembly/return_instead_of_leave.py

Additional comments: 127

tests/e2e/solc_parsing/test_data/event-top-level.sol (2)

1-1: The top-level event declaration MyEvent is correctly defined and follows Solidity best practices for event naming and parameter types.

3-7: The contract T and its function a are correctly implemented to emit the MyEvent event. This is a simple and straightforward use case demonstrating event emission in Solidity.

tests/e2e/detectors/test_data/incorrect-shift/0.7.6/shift_parameter_mixup.sol (2)

8-9: The Solidity shift operation uint g = 0xff << y; is correctly implemented. It demonstrates a left shift operation, which is a common operation in Solidity for bit manipulation.

5-11: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [3-9]

The assembly block within function f uses shr and shl operations for right and left shifts, respectively. However, the usage of a as both an input and output for shr might be incorrect without prior assignment. Ensure a is correctly assigned before use in the assembly block.

tests/e2e/detectors/snapshots/detectors__detector_ShiftParameterMixup_0_7_6_shift_parameter_mixup_sol__0.txt (1)

1-1: The reported incorrect shift operation in C.f() is accurately described, including the specific line range and operation details. This snapshot file correctly captures the essence of the detected issue.

tests/e2e/detectors/snapshots/detectors__detector_ShiftParameterMixup_0_6_11_shift_parameter_mixup_sol__0.txt (1)

1-1: The reported incorrect shift operation for a different Solidity version in C.f() is accurately captured, indicating consistency in detecting issues across different versions.

tests/e2e/detectors/test_data/incorrect-shift/0.4.25/shift_parameter_mixup.sol (2)

8-9: The Solidity shift operation uint g = 0xff << y; is correctly implemented for version 0.4.25, demonstrating the use of shift operations for bit manipulation in older Solidity versions.

3-9: The assembly block within function f correctly uses shr and shl operations for shifting. As with the 0.7.6 version, ensure that variable a is assigned a value before its use in the assembly block to avoid potential issues.
tests/e2e/detectors/test_data/incorrect-shift/0.5.16/shift_parameter_mixup.sol (2)
8-9: The Solidity shift operation uint g = 0xff << y; is correctly implemented for version 0.5.16. This consistency across versions demonstrates a good understanding of shift operations in Solidity.

3-9: The assembly block within function f uses shr and shl correctly for version 0.5.16. As before, ensure that a is assigned before its use in the assembly block to maintain correctness.

Verification successful

The review comment is correct in highlighting the concern that the variable a should be assigned before its use in the assembly block. The provided code snippet does not show any assignment to a prior to its use within the assembly block, which is necessary for maintaining correctness in Solidity version 0.5.16.
Scripts Executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Manual verification needed to ensure variable `a` is correctly assigned before its use in assembly for Solidity version 0.5.16.
echo "Manual check required for assembly block variable usage in C.f() for Solidity version 0.5.16"
Length of output: 194

Script:
#!/bin/bash
# Search for the function `f` in `shift_parameter_mixup.sol` and display the code surrounding the assembly block
rg --context 10 "function f" tests/e2e/detectors/test_data/incorrect-shift/0.5.16/shift_parameter_mixup.sol
Length of output: 331
tests/e2e/detectors/test_data/incorrect-shift/0.6.11/shift_parameter_mixup.sol (2)
8-9: The Solidity shift operation uint g = 0xff << y; is correctly implemented for version 0.6.11, showing a consistent application of shift operations across different Solidity versions.

3-9: The assembly block within function f correctly uses shr and shl operations for version 0.6.11. Ensure that a is properly assigned before its use in the assembly block to avoid potential issues.
Verification successful

The output from the script contains a significant amount of binary or non-text data before revealing the content of the shift_parameter_mixup.sol file. This non-text data likely represents a misinterpretation of the file's content or an issue with how the file was accessed. However, towards the end of the output, we finally see the relevant Solidity code snippet:
contract C { 

    function f() internal returns (uint a, uint b) { 
        assembly { 
            a := shr(a, 8) 
            b := shl(248, 0xff)
        } 
        uint y = 1;
        uint g = 0xff << y;
    } 
}
This snippet confirms the structure of the function f within the contract C, including the assembly block that uses shr and shl operations. However, it does not explicitly show the initialization of the variable a before its use in the assembly block, which was the primary concern of the review comment.

Given the information at hand, it's clear that the variable a is not assigned a value before its use in the assembly block, which could lead to undefined behavior or unexpected results. The review comment's concern about ensuring a is properly assigned before its use in the assembly block is valid based on the Solidity code structure shown.

Therefore, the review comment is verified as the code snippet does not demonstrate an assignment to a before its use in the assembly block, which could potentially lead to issues.
Scripts Executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Manual verification needed to ensure variable `a` is correctly assigned before its use in assembly for Solidity version 0.6.11.
echo "Manual check required for assembly block variable usage in C.f() for Solidity version 0.6.11"
Length of output: 194

Script:
#!/bin/bash
# Display the content of the file to check the initialization and usage of `a` before the assembly block.
fd shift_parameter_mixup.sol --exec cat {}
Length of output: 8333
tests/e2e/detectors/snapshots/detectors__detector_Suicidal_0_7_6_suicidal_sol__0.txt (1)

1-2: The snapshot accurately reports two functions within the C contract that allow for self-destruction, clearly indicating the potential security risk associated with such functionality.

slither/core/declarations/event_top_level.py (1)

10-13: The EventTopLevel class is correctly defined and follows Python best practices for class inheritance and constructor definition. The use of type annotations enhances code readability and maintainability.

slither/tools/mutator/utils/command_line.py (1)

11-18: The simplification of the data structure for mutators and the updated table creation logic in output_mutators function are correctly implemented. The use of a sorted list to organize mutators by their argument enhances readability and maintainability.

slither/core/declarations/event_contract.py (1)

10-25: The EventContract class is correctly defined, providing methods to check if an event is declared by a contract and to generate a canonical name for the event. The implementation follows Python best practices, including the use of type annotations and docstrings to enhance code readability and maintainability.

.github/workflows/pip-audit.yml (1)

24-24: The update of the setup-python action to version v5 in the pip-audit workflow is correctly implemented. This change ensures the workflow uses the latest version of the action, potentially benefiting from improvements and bug fixes.

slither/tools/mutator/utils/patch.py (1)

6-29: The create_patch_with_line function is correctly implemented, providing functionality to create a patch with detailed line information. The handling of string and byte types using .decode("utf8") ensures compatibility and prevents potential encoding issues. The use of a defaultdict for organizing patches by file enhances the function's usability and maintainability.

slither/core/declarations/__init__.py (1)

4-5: The addition of imports for EventContract and EventTopLevel in the declarations module is correctly implemented. These imports enhance the module's functionality by making these classes available for use elsewhere in the codebase.

slither/tools/mutator/mutators/all_mutators.py (1)

2-16: The addition of new mutators and the update of import statements in all_mutators.py are correctly implemented. The categorization of mutators by severity levels (low, medium, high) is clear and enhances the understanding of their potential impact. This update expands the tool's capabilities in mutation testing.

slither/core/declarations/event.py (1)

7-7: The modifications to the Event class, including the removal of inheritance from ContractLevel and adjustments to method implementations, are correctly implemented. These changes streamline the class and focus its functionality on event-specific properties and behaviors.

.github/actions/upload-coverage/action.yml (1)

24-24: The update of the upload-artifact action to version v4 in the workflow for uploading coverage is correctly implemented. This change ensures the workflow uses the latest version of the action, potentially benefiting from improvements and bug fixes.

.github/workflows/docs.yml (1)

33-46: The updates to the versions of configure-pages, setup-python, upload-pages-artifact, and deploy-pages actions in the docs workflow are correctly implemented. These changes ensure the workflow uses the latest versions of these actions, potentially benefiting from improvements and bug fixes. The workflow configuration appears to be correctly structured for building and deploying documentation.

tests/e2e/detectors/snapshots/detectors__detector_OutOfOrderRetryable_0_8_20_out_of_order_retryable_sol__0.txt (1)

1-16: The output clearly identifies multiple instances of retryable tickets being created in the same function, providing specific line references to the source code. This is helpful for pinpointing the exact locations of potential issues. However, ensure that the referenced lines in the source code (out_of_order_retryable.sol) accurately reflect these instances for correctness.

slither/tools/upgradeability/checks/variable_initialization.py (1)

46-47: The update to iterate over stored_state_variables_ordered and the simplified condition if s.initialized are clear and concise. Ensure that stored_state_variables_ordered accurately reflects the intended set of variables for this check, considering the context of upgradeability and initialization.

.github/workflows/pylint.yml (1)

32-32: Updating the setup-python action to version v5 is a good practice to ensure compatibility with the latest features and security patches. Verify that all Python-related actions in the workflow function as expected with this version update.

Dockerfile (1)

50-50: Switching to solc-select use latest --always-install ensures that the Docker image always uses the latest version of the Solidity compiler. This is beneficial for staying up-to-date with compiler features and security fixes. However, consider the potential impact on reproducibility and testing, as builds may vary over time with different compiler versions.

slither/tools/mutator/mutators/CR.py (1)

7-39: The implementation of the "Comment Replacement" mutator (CR) appears to be correct and follows the intended logic of adding comments to specific parts of the code. Ensure that the conditions for mutation (if not line_no[0] in self.dont_mutate_line) are correctly defined and that the mutation does not inadvertently alter the logic of the original code.

slither/tools/mutator/mutators/RR.py (1)

7-38: The "Revert Replacement" mutator (RR) correctly identifies and replaces specific strings with revert(). Ensure that this replacement logic is applied only where intended and does not introduce unintended side effects in the mutated code.

slither/tools/mutator/mutators/FHR.py (1)

15-42: The "Function Header Replacement" mutator (FHR) correctly applies regular expression replacements to function headers. Ensure that the regular expressions and replacement logic accurately reflect the intended mutations without affecting the syntactical correctness of the code.

tests/e2e/detectors/test_data/msg-value-loop/0.4.25/msg_value_loop.sol (1)

29-62: The added functions (good1, good2, good3, good4) demonstrate various ways to handle msg.value checks before performing operations. These examples are useful for illustrating secure patterns in handling Ether transfers. Ensure that these patterns are consistently applied across the contract to mitigate risks associated with incorrect msg.value handling.

tests/e2e/detectors/test_data/msg-value-loop/0.5.16/msg_value_loop.sol (1)

29-62: The functions added for handling msg.value checks (good1, good2, good3, good4) are consistent with secure smart contract practices. It's important to ensure that these examples are relevant and correctly implemented for the specific Solidity version (0.5.16) they are intended for.

tests/e2e/detectors/test_data/msg-value-loop/0.6.11/msg_value_loop.sol (1)

29-62: The functions (good1, good2, good3, good4) added to handle msg.value checks are well-implemented and follow secure smart contract practices. As with other versions, ensure these practices are suitable and correctly applied for Solidity version 0.6.11.

tests/e2e/detectors/test_data/msg-value-loop/0.7.6/msg_value_loop.sol (1)

29-62: The functions (good1, good2, good3, good4) added to handle msg.value checks are consistent with secure smart contract practices for Solidity version 0.7.6. Ensure that these examples are correctly implemented and provide valuable insights into handling msg.value securely.

tests/e2e/detectors/test_data/msg-value-loop/0.8.0/msg_value_loop.sol (1)

29-62: The functions (good1, good2, good3, good4) added to handle msg.value checks are well-implemented and follow secure smart contract practices for Solidity version 0.8.0. Ensure that these examples are correctly implemented and provide valuable insights into handling msg.value securely.

.github/workflows/linter.yml (1)

34-34: Updating the setup-python action to version v5 is a good practice to ensure compatibility with the latest features and security patches. Verify that all Python-related actions in the workflow function as expected with this version update.
slither/solc_parsing/declarations/event.py (2)
19-24: The constructor of EventSolc now accepts an instance of SlitherCompilationUnitSolc as an argument. This change aligns with the objective to use a compilation unit for parsing instead of a contract, which can provide a broader context for parsing operations. Ensure that all calls to this constructor throughout the codebase have been updated to pass the correct type of argument.

Verification successful

The search for instances where EventSolc is instantiated in Python files has yielded two results: in slither/solc_parsing/slither_compilation_unit_solc.py and slither/solc_parsing/declarations/contract.py. Both instances pass self as the last argument, which aligns with the updated constructor accepting an instance of SlitherCompilationUnitSolc. This confirms that the necessary updates to pass the correct type of argument have been made in these locations.
Scripts Executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Search to find files that instantiate EventSolc. Expecting list of dependent files.
rg --type python $'new EventSolc\('
Length of output: 67

Script:
#!/bin/bash
# Correcting the search to find files that instantiate EventSolc, specifically targeting Python files.
rg --type py 'new EventSolc\('
Length of output: 32

Script:
#!/bin/bash
# Correcting the search to accurately find files that instantiate EventSolc, by omitting the 'new' keyword, which is not used in Python.
rg --type py 'EventSolc\('
Length of output: 316
* 47-54: The `analyze` method iterates over elements to parse and creates `EventVariable` instances. It's crucial to ensure that the parsing logic correctly handles the new structure provided by `SlitherCompilationUnitSolc`. Specifically, verify that `self._slither_parser.compilation_unit` correctly provides the necessary context for source offset setting and that the parsing of event variables is accurate and comprehensive.
Consider adding unit tests to validate the parsing logic for various event structures to ensure robustness.
tests/e2e/compilation/test_resolution.py (1)

60-62: The updated assertions in the test method test_contract_function_parameter correctly compare the names of function parameters as strings. This change ensures that the test accurately validates the names of parameters defined in the contract function. It's important to ensure that the test covers all relevant cases and that the parameter names used in the assertions match those defined in the contract being tested.

.github/workflows/ci.yml (3)

58-58: The update to use actions/setup-python@v5 is a good practice to ensure the workflow uses the latest features and fixes of the setup-python action. Ensure that the Python projects in this repository are compatible with the changes introduced in version 5.

70-70: Updating cachix/install-nix-action to version v25 is beneficial for leveraging the latest improvements and compatibility fixes. Verify that the Nix environment setup by this action remains compatible with the project's requirements.

74-74: The update to cachix/cachix-action@v14 ensures the workflow benefits from the latest enhancements and stability improvements of the cachix action. Confirm that the caching behavior aligns with the project's caching strategy and that there are no regressions.

.github/workflows/doctor.yml (1)

35-35: The update to actions/setup-python@v5 in the doctor.yml workflow is appropriate for ensuring the use of the latest version of the setup-python action. This change can help leverage new features and bug fixes. It's important to verify that all Python-related workflows function as expected with this version update.

slither/detectors/functions/suicidal.py (1)

62-62: Replacing func.internal_calls with func.all_internal_calls() in the detect_suicidal_func function is a significant improvement. This change ensures that the detection logic considers all internal calls, including those from inherited contracts, which can provide a more comprehensive analysis of suicidal patterns. Ensure that this method is thoroughly tested to confirm its accuracy in various contract structures.
tests/e2e/detectors/test_data/out-of-order-retryable/0.8.20/out_of_order_retryable.sol (2)
61-81: The function bad2 correctly demonstrates sequential calls to createRetryableTicket without any conditional checks. This is a valid demonstration of a pattern, assuming the intention is to show multiple ticket creations in a single transaction. No changes are necessary, but ensure the purpose is documented.

82-92: In bad3, the call to good2() is made after a createRetryableTicket call. This function mixes external contract interactions with internal logic, which could lead to reentrancy issues if not handled properly. Ensure that good2 does not perform any actions that could change the state in an unexpected way after the external call.

Verification successful

The verification process has confirmed that good2 makes an external contract call to createRetryableTicket, similar to the call made in bad3. Given that good2 is called immediately after another external contract interaction within bad3, there is a potential for reentrancy issues. This aligns with the initial review comment's concern about mixing external contract interactions with internal logic, which could lead to reentrancy vulnerabilities if not handled properly. Therefore, it is crucial to ensure that good2 does not perform any actions that could change the state in an unexpected way after the external call.
Scripts Executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Verify that good2 does not introduce reentrancy issues
grep -C 3 "function good2" out_of_order_retryable.sol
Length of output: 115

Script:
#!/bin/bash
# Locate the file out_of_order_retryable.sol and inspect the implementation of good2
fd out_of_order_retryable.sol --exec grep -C 3 "function good2" {}
Length of output: 223
slither/tools/properties/__main__.py (1)

71-72: The updated description and usage message in the argparse.ArgumentParser provide clearer and more specific information about the program's purpose and usage. This is a positive change that enhances the user's understanding of how to use the tool effectively.

slither/tools/mutator/mutators/UOR.py (1)

19-87: The mutation logic in the UOR mutator correctly identifies unary operations and generates mutations by replacing the operator. However, there are a few considerations:

Ensure that the replacement of unary operators does not introduce syntax errors or change the semantics of the code in an unintended way.

The handling of both prefix and postfix operations appears to be correct, but it's important to verify through testing that the generated mutations are valid and meaningful.

Overall, the approach seems sound, but thorough testing is recommended to ensure the quality of the mutations.

slither/tools/mutator/mutators/LIR.py (1)

15-85: The mutation logic in the LIR mutator correctly identifies literal integers and generates mutations by replacing these literals with minimum, maximum, or specific values. However, there are a few considerations:

Ensure that the replacement of literal integers does not introduce logic errors or significantly alter the behavior of the code in an unintended way.

The handling of both state and local variable initializations appears to be correct, but it's important to verify through testing that the generated mutations are valid and meaningful.

Overall, the approach seems sound, but thorough testing is recommended to ensure the quality of the mutations.

slither/tools/mutator/utils/file_handling.py (1)

10-130: The file handling utilities in file_handling.py provide essential operations for the mutation testing framework, including backing up source files, transferring and deleting files, creating mutant files, and resetting files. A few considerations:

Ensure that file operations are performed safely, especially when dealing with file paths and content manipulation.

Verify that the backup and reset mechanisms work as expected to prevent data loss during mutation testing campaigns.

Consider adding error handling for file operations to gracefully handle exceptions and provide meaningful error messages to the user.

Overall, the implementation seems to address the necessary file handling operations for mutation testing, but thorough testing and error handling improvements are recommended.

slither/tools/mutator/mutators/abstract_mutator.py (1)

71-120: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [17-120]

The updates to the AbstractMutator class introduce new parameters to the constructor and enhance the mutate method to better handle mutation testing and patching. A few considerations:

Ensure that the new parameters are correctly used throughout the class and provide meaningful functionality to the mutation testing process.

The updated mutate method now includes logic for testing patches and handling mutation statistics. Verify that this logic is accurate and efficiently implemented.

Consider adding documentation for the new parameters and the updated method to help users and developers understand their purpose and usage.

Overall, these updates seem to significantly improve the mutation testing framework's flexibility and functionality. However, thorough testing and documentation are recommended to ensure their effectiveness.

slither/detectors/variables/unchanged_state_variables.py (2)

28-28: The simplification of the _valid_candidate function in the detection of state variables that could be declared as constant or immutable is a positive change. It streamlines the process of identifying valid candidates by focusing on the variable type. However, ensure that this simplification does not overlook any edge cases where additional checks might be necessary.

95-95: The update to the detect method, specifically the replacement of variables.append(c.state_variables) with variables.append(c.stored_state_variables), is a meaningful change. It ensures that only stored state variables are considered for detection, potentially reducing false positives. Verify through testing that this change accurately captures the intended state variables without excluding relevant cases.

slither/tools/mutator/mutators/SBR.py (1)

51-109: The mutation logic in the SBR mutator correctly identifies patterns in Solidity code and generates mutations by applying predefined replacement rules. However, there are a few considerations:

Ensure that the replacement rules do not introduce syntax errors or significantly alter the semantics of the code in an unintended way.

Verify through testing that the generated mutations are valid and meaningful, especially considering the wide range of replacement rules defined.

Overall, the approach seems sound, but thorough testing is recommended to ensure the quality of the mutations.

slither/tools/read_storage/__main__.py (2)

10-10: The addition of SlitherError import from slither.exceptions is appropriate for error handling within the tool.

133-134: Raising a SlitherError when no contracts are found for the specified contract name is a good practice for error handling. It ensures that the user is informed of the issue in a clear manner.

slither/solc_parsing/yul/evm_functions.py (2)

56-72: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [48-69]

The addition of new EVM opcodes (MCOPY, BASEFEE, BLOBHASH, BLOBBASEFEE, TLOAD, TSTORE) to the evm_opcodes list is correctly implemented. This update ensures that the tool remains up-to-date with the latest EVM specifications.

192-201: The corresponding stack requirements for the newly added opcodes (TLOAD, TSTORE, BASEFEE, BLOBHASH, BLOBBASEFEE) are correctly defined in the function_args dictionary. This is crucial for accurate parsing and analysis of Yul and EVM bytecode.

examples/scripts/data_dependency.py (1)

130-142: The addition of code to interact with the SimpleModifier contract and check dependencies within a modifier function is a valuable example. It demonstrates how to use the is_dependent function to analyze data dependencies in smart contracts. This can be particularly useful for developers looking to understand the flow of data within their contracts.

slither/core/variables/variable.py (1)

96-101: The addition of the is_stored property is a useful enhancement for determining if a variable is stored, based on it not being constant or immutable. This property could be particularly useful for analyses that need to differentiate between stored variables and those that are constant or immutable. The documentation comment provides clear guidance on its purpose and potential future adjustments.

slither/detectors/functions/out_of_order_retryable.py (1)

1-155: This file appears to introduce or update functionality related to detecting out-of-order retryable transactions. While specific changes are not annotated, the presence of this detector is crucial for identifying potential issues with retryable tickets in smart contracts, especially in the context of cross-chain or layer 2 solutions. It's important to ensure comprehensive testing and validation of this detector to maintain the robustness of the analysis.

slither/detectors/variables/predeclaration_usage_local.py (1)

39-39: The correction in the WIKI_EXPLOIT_SCENARIO section from z to x improves the documentation's accuracy, making it clearer for users to understand the potential issues this detector can identify.

slither/detectors/statements/divide_before_multiply.py (1)

136-136: The modification to iterate over both functions and modifiers declared in a contract enhances the detector's comprehensiveness and accuracy, ensuring that all relevant entities are considered in the analysis.

examples/scripts/possible_paths.py (1)

22-22: The modification to filter functions based on their declared names instead of their original names in the resolve_function function improves the script's accuracy and functionality, ensuring correct function resolution.

slither/core/declarations/solidity_variables.py (2)

24-25: The updates to block.basefee and the addition of block.blobbasefee as uint256 in SOLIDITY_VARIABLES_COMPOSED align with Solidity's evolving specifications, ensuring the framework remains up-to-date.

48-48: The introduction of the blobhash(uint256) function with return type bytes32 in SOLIDITY_FUNCTIONS expands the framework's coverage of Solidity's built-in functionalities, enhancing its comprehensiveness.

slither/utils/encoding.py (1)

71-77: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [74-81]

The modification in encode_var_for_compare to determine the slot of a variables.StateVariable based on its storage status is a logical enhancement. This change ensures that the encoding reflects the actual storage layout, which is critical for accurate analysis in smart contract security, especially concerning upgradeability and storage layout compatibility. The use of exception handling for KeyError when determining the slot suggests robustness in handling incomplete or missing storage layout information. However, it's essential to ensure that this change is thoroughly tested, especially in edge cases where storage layout information might be ambiguous or incomplete.

slither/tools/upgradeability/checks/variables_order.py (2)

118-119: The update to use stored_state_variables_ordered directly in both DifferentVariableContractProxy and ExtraVariablesProxy classes simplifies the logic for obtaining state variables in their defined order. This change is beneficial for upgradeability checks, ensuring that the variables' order is consistent with their declaration in the contract, which is crucial for maintaining storage layout compatibility. It enhances readability and maintainability by relying on a more straightforward approach to retrieve state variables.

239-240: Similarly, the use of stored_state_variables_ordered in the ExtraVariablesProxy class for identifying extra variables in the proxy compared to the contract simplifies the logic and ensures accuracy in detecting additional variables that could affect storage layout compatibility. This change maintains the focus on readability and maintainability, making the upgradeability checks more straightforward and reliable.

slither/tools/documentation/__main__.py (1)

24-27: The updates to the parse_args function, including the enhanced description and usage details, clearly communicate the tool's capability to auto-generate NatSpec documentation for Solidity functions using OpenAI Codex. This improvement is essential for guiding users on how to utilize the tool effectively, ensuring they understand its purpose and how to execute it correctly. The explicit mention of OpenAI Codex in the description also sets the right expectations regarding the tool's underlying technology.

slither/core/scope/scope.py (2)

39-39: The introduction of the events dictionary in the Scope class is a significant enhancement, enabling the tool to handle and analyze events declared in smart contracts. This addition aligns with the need to support comprehensive analysis of smart contracts, considering that events are a fundamental aspect of Ethereum contracts for logging and communication purposes.

79-81: The logic to merge events from accessible scopes ensures that the tool can accurately account for events declared across different contracts and files, enhancing the analysis's comprehensiveness. This approach is crucial for accurately understanding contracts' behavior and interactions, especially in complex projects with multiple contracts and dependencies.

slither/tools/mutator/__main__.py (6)

5-7: The imports for os, shutil, and Optional have been added. These are standard Python libraries and their usage is appropriate for file operations and type hinting.

21-21: The logger has been renamed to "Slither-Mutate". This is a good practice for identifying logs specific to the mutation functionality.

32-38: The parse_args function has been updated with a more descriptive description and usage information. This enhances the usability and clarity of the command-line interface.

52-94: New command-line arguments have been added to support mutation testing features such as specifying test commands, directories, timeouts, mutators selection, contract names, and verbose output. These additions are crucial for providing flexibility and control over the mutation testing process.

106-117: The _get_mutators function has been introduced to organize mutators based on the provided list. This function improves the modularity and maintainability of the code by separating the logic for mutator selection.

138-251: Significant enhancements have been made to the main function, including handling of new command-line arguments, organizing mutators, handling exceptions, and cleaning up after interruptions. These changes are comprehensive and improve the mutation functionality by making it more robust and user-friendly.

slither/slither.py (2)

135-138: The inclusion of paths during the initialization process has been added. This allows for more granular control over which paths are included in the analysis, enhancing the flexibility of the tool.

142-144: A new triage_database option with a default value has been introduced. This feature is beneficial for managing previous results and facilitating a triage process, improving the tool's usability for continuous analysis.

slither/core/compilation_unit.py (3)

19-19: Support for handling events at the top level has been added through the import of EventTopLevel. This is a significant addition as it extends the tool's capability to analyze and work with events in smart contracts.

61-61: The property events_top_level has been introduced to provide access to top-level events. This addition is crucial for enabling comprehensive analysis and manipulation of events within the compilation unit.

305-305: The storage layout computation has been adjusted to use stored state variables instead of all state variables. This change is important for accurately calculating the storage layout, considering only the variables that are stored in the contract's storage.

slither/utils/command_line.py (2)

63-63: The addition of the include_paths option to the command-line interface configuration is a positive enhancement. It presumably allows users to specify additional directories or files to be included in the analysis. This could be particularly useful for projects with complex directory structures or when certain dependencies are located outside the default search paths. Ensure that the handling of this option is implemented consistently across the tool, including proper path resolution and error handling for non-existent paths.

74-74: The introduction of the triage_database option, with a default value of "slither.db.json", is an interesting feature. This option likely enables users to specify a database file for storing and managing triage information related to the analysis findings. It's important to ensure that the database interactions are secure, especially regarding data validation and error handling. Additionally, consider providing documentation or examples on how to effectively use this feature, as it could significantly enhance the user experience by allowing persistent management of analysis results.

slither/solc_parsing/expressions/find_variable.py (1)

137-139: The addition of a check for var_name in scope.events within the find_top_level function is a valuable enhancement. This change ensures that event declarations at the top level are properly recognized and handled by the tool. It's crucial for the accurate parsing and analysis of Solidity contracts, especially for those utilizing events for logging or other purposes. Ensure that this new check is thoroughly tested with various contract structures to confirm its reliability and effectiveness in identifying event declarations correctly.

slither/tools/flattening/flattening.py (1)

80-80: The addition of _get_source_code_top_level(compilation_unit.events_top_level) ensures that the source code for top-level events is correctly retrieved and stored. This change is crucial for maintaining the completeness and accuracy of the flattening process, especially given the importance of events in smart contract systems for logging and monitoring purposes. It's a good practice to ensure that all relevant top-level declarations are considered in such utilities, enhancing the tool's utility and reliability.
tests/e2e/solc_parsing/test_ast_parsing.py (4)
24-29: The addition of the solc_args parameter to the Test class constructor is a significant change. It's important to ensure that all instances of Test in this file and potentially in other parts of the project are updated to handle this new parameter correctly. This change allows for more flexible configuration of Solidity compiler arguments in tests, which can be particularly useful for testing different compiler settings or versions.

Verification successful

The review comment is verified. Instances were found in test_detectors.py where the Test class is instantiated without the newly added solc_args parameter, indicating that the codebase may need to be updated to include this parameter where necessary.
Scripts Executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Search for instances of the Test class being instantiated without the new solc_args parameter.
ast-grep --lang python --pattern $'Test($_, $_, $_, $_)'
Length of output: 1642
* 21-38: > 📝 **NOTE** > This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [35-51]
The logic for appending versions_with_flavors now includes the solc_args parameter. This is a crucial update for ensuring that each test version and flavor can be associated with specific Solidity compiler arguments. However, it's important to verify that the solc_args parameter is being correctly utilized wherever versions_with_flavors is processed. This change enhances the flexibility and specificity of test configurations, which is beneficial for comprehensive testing across different compiler settings.

473-473: The addition of solc_args="--evm-version cancun" in the instantiation of the Test class for the "solidity-0.8.24.sol" test case is a specific example of how the new solc_args parameter can be utilized to test against a particular EVM version. This is a good practice as it allows for targeted testing of compiler behavior with different EVM versions, ensuring that the project's tools and functionalities are compatible across various Solidity and EVM versions.

603-611: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [594-608]

The _generate_compile function has been updated to pass the solc_args parameter to CryticCompile. This ensures that the specified Solidity compiler arguments are used when compiling the test contracts. It's important to ensure that the solc_args parameter is correctly handled within CryticCompile to apply the compiler arguments as intended. This change is crucial for enabling more flexible and specific compiler configurations in the test setup, which can help identify issues and behaviors that only manifest under certain compiler settings.
slither/core/slither_core.py (3)

65-65: The addition of the _paths_to_include set attribute in the __init__ method is a straightforward change. It's initialized as an empty set, which is consistent with the initialization pattern for similar attributes in this class.

273-274: The update to _compute_offsets_to_ref_impl_decl to handle events from top-level compilation units is a logical extension of the existing functionality. This change ensures that events, like other top-level entities (functions, enums, etc.), are properly processed for source mapping. It's important to ensure that all event-related functionalities are tested to verify that events are correctly handled across the tool.

508-514: The addition of the add_path_to_include method is consistent with the existing add_path_to_filter method, allowing for paths to be explicitly included in the analysis. This method enhances the flexibility of result filtering, enabling users to specify paths that should always be considered, regardless of other filtering criteria. It's important to document the expected behavior when paths are added to both the include and filter sets to avoid confusion.

slither/utils/upgradeability.py (4)

84-85: The switch to using stored_state_variables_ordered instead of filtering based on is_constant or is_immutable properties is a significant change. This adjustment seems to align with the goal of focusing on variables that are stored and potentially impact the state of the contract across upgrades. Ensure that all dependent functionalities are updated to accommodate this change.

205-205: The condition target.is_stored is used to determine if a state variable is considered tainted. This change from checking is_constant or is_immutable to is_stored is consistent with the focus on stored state variables. It's important to verify that this new condition accurately captures all relevant scenarios for tainting variables in the context of contract upgrades.

303-304: The use of stored_state_variables_ordered in get_missing_vars function aligns with the overall changes in this file, focusing on stored state variables for upgradeability checks. This consistency is crucial for ensuring that the upgradeability analysis remains accurate and comprehensive.

361-361: The condition if delegate.is_stored: in the context of getting the proxy implementation slot is a logical extension of the changes made throughout this file. It ensures that only stored variables are considered when determining the storage slot for a proxy's implementation address. This change enhances the accuracy of identifying the correct storage slot in upgradeable contracts.

slither/vyper_parsing/declarations/contract.py (2)

27-27: The update from importing Event to EventContract is a straightforward change that aligns with the naming conventions used elsewhere in the project. This change should be cross-verified to ensure that all references to Event are now correctly pointing to EventContract.

481-481: The modification in the parse_events method to instantiate EventContract instead of Event is consistent with the import change. This ensures that the correct class is used throughout the file. It's important to verify that this change does not affect the functionality of event parsing in any adverse way.

README.md (5)

49-49: The addition of support for Vyper smart contracts is a significant enhancement. It broadens the tool's applicability and utility for developers working with both Solidity and Vyper smart contracts. This change aligns with the PR's objective of enhancing smart contract support capabilities.

76-76: The updated installation command for slither-analyzer using pip ensures users are directed to use the correct method for installing the tool. This change is straightforward and improves the clarity of the installation instructions.

83-83: The installation instructions for users preferring to install Slither via Git have been updated to include a specific command. This ensures clarity and consistency in the documentation, guiding users through the installation process effectively.

134-134: Updating the detector documentation link for incorrect-return ensures users have access to the most current and accurate information regarding this detector. It's crucial for maintaining the documentation's relevance and usefulness.

137-137: Similarly, updating the detector documentation link for return-leave ensures that users are directed to the correct and updated information. This change is important for keeping the documentation accurate and helpful for users seeking information about this specific detector.

slither/__main__.py (5)

271-274: The implementation of parse_filter_paths correctly handles the new filter_path parameter to differentiate between filter_paths and include_paths. This change improves the flexibility of path filtering.

311-311: The introduction of a mutually exclusive group for filter options using parser.add_mutually_exclusive_group() is a good practice. It ensures that users cannot specify conflicting filter options simultaneously, enhancing the command-line interface's usability.

525-537: Renaming --triage-mode to --triage-database and changing its functionality to specify the triage database file path is a significant improvement. It provides clarity and flexibility in specifying the database for triage results.

584-590: The addition of the --include-paths option is a valuable enhancement. It complements the existing --filter-paths option by allowing users to specify paths that should be included, offering more granular control over the analysis scope.

644-645: The update to call parse_filter_paths with the appropriate boolean flag for both filter_paths and include_paths ensures that the new command-line options are correctly processed and applied. This change effectively integrates the new filter path options into the existing framework.

slither/solc_parsing/declarations/contract.py (2)

7-7: Renaming Event to EventContract improves clarity by distinguishing event declarations within contracts from other possible event-related classes or functions in the codebase. This change aligns with best practices for naming, making the code more readable and maintainable.

750-755: The addition of self._slither_parser as an argument to the EventSolc constructor and method calls is a significant change. This modification likely aims to enhance the event parsing capabilities by providing more context or functionality from the SlitherCompilationUnitSolc instance. However, it's crucial to ensure that all calls to EventSolc throughout the codebase have been updated to include this new argument to maintain consistency and avoid runtime errors.

slither/solc_parsing/slither_compilation_unit_solc.py (3)

13-13: The import statement for EventTopLevel is correctly added to support the new functionality for event parsing. This aligns with the PR's objective to enhance support for smart contract development.

27-27: The import statement for EventSolc is correctly added, indicating the introduction of a new class for handling the parsing of events in Solidity code. This is a necessary addition for the new feature implementation.

352-359: The addition of the EventDefinition case in the parse_top_level_items method is well-implemented. It correctly instantiates EventTopLevel, sets its offset, and uses EventSolc for further analysis. This change effectively integrates event parsing into the existing structure, ensuring that events are now recognized and processed at the top level of Solidity files. However, it's important to ensure that event_parser.analyze() is thoroughly tested to handle various event definitions correctly.

slither/tools/read_storage/read_storage.py (1)

401-401: The modification from checking var.is_constant and not var.is_immutable to var.is_stored simplifies the condition for identifying target variables. This change likely reflects an update in how storage variables are categorized or identified within the Slither project. Ensure that this new condition accurately captures all intended storage variables without inadvertently excluding any cases that the previous condition covered.

slither/core/cfg/node.py (2)

902-908: The logic for handling sstore operations seems correct, identifying calls to sstore(uint256,uint256) and marking the first argument as a written variable. However, it's important to ensure that ir.arguments[0] is the correct way to access the variable being written to. Typically, sstore operations involve writing to storage, and the first argument represents the storage slot. Confirm that ir.arguments[0] correctly references the storage slot or variable being written to, and not another parameter or value.

910-916: Similar to the handling of sstore, the handling of sload operations is aimed at identifying reads from storage. The condition checks for sload(uint256) calls within an assignment operation, marking the first argument as a read variable. This logic appears to correctly capture the intent of sload operations. However, ensure that ir.arguments[0] accurately represents the storage slot being read from. In Solidity, sload is used to read from a specific storage slot, and it's crucial that ir.arguments[0] correctly identifies this slot.

tests/e2e/detectors/test_detectors.py (1)

1682-1686: The addition of the OutOfOrderRetryable test case is a valuable contribution to ensuring the robustness of the detector suite. However, it's crucial to verify that the corresponding test data (out_of_order_retryable.sol) and the expected results are correctly set up and that they accurately reflect the scenarios this detector is meant to catch.

slither/core/declarations/contract.py (4)

36-36: The renaming of Event to EventContract is correctly reflected in the import section. This change aligns with the summary provided and should help clarify the distinction between generic events and those specifically related to contracts.

76-76: The type of the _events dictionary is correctly updated to Dict[str, "EventContract"]. This change is consistent with the renaming of Event to EventContract and ensures type safety and clarity in the codebase.

436-468: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [281-464]

The properties events, events_inherited, events_declared, and events_as_dict have been correctly updated to return lists or dictionaries of EventContract instead of Event. This change is necessary following the renaming of Event to EventContract and ensures that the code remains consistent and type-safe.

439-464: The addition of stored_state_variables and stored_state_variables_ordered properties is a significant enhancement. These properties filter state variables with storage locations, which is crucial for smart contract analysis and manipulation. The implementation correctly filters out constant or immutable state variables, adhering to the Solidity language specifications. This addition aligns with the PR's objectives to refine the project's core functionalities and tools.

slither/solc_parsing/declarations/function.py (3)

999-1001: The addition of the ENDASSEMBLY node creation after processing inline assembly statements is a good practice for maintaining a clear and understandable control flow graph (CFG). This change ensures that the end of an assembly block is explicitly marked, which can be crucial for further analyses or transformations of the CFG. However, it's important to ensure that this new node type is properly handled in all relevant parts of the codebase, including any CFG traversals or analyses that might be affected by the introduction of this new node type.

1111-1117: Refactoring the _update_reachability method to use a worklist approach is a significant improvement in terms of both performance and readability. This change eliminates the potential for stack overflow errors that could occur with a recursive approach, especially in the case of deeply nested or complex control flow graphs. Additionally, the worklist approach is more in line with standard algorithms for CFG traversal, making the code more maintainable and understandable for future contributors. It's important to verify that this change has been thoroughly tested, especially in edge cases such as cyclic graphs or graphs with unreachable nodes.

1108-1120: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-1117]

Overall, the file demonstrates a comprehensive approach to parsing and handling Solidity functions within the Slither framework. The changes introduced in this pull request, including the addition of the ENDASSEMBLY node and the refactoring of the _update_reachability method, are well-considered and improve the codebase. It's recommended to continue adhering to best practices for code quality, including thorough testing, clear documentation, and consistent code style. Additionally, given the complexity of the domain, it's crucial to ensure that the parsing logic accurately reflects the latest Solidity language features and specifications.

slither/slithir/convert.py (1)

633-643: The addition of a condition to handle library functions when used with "this" and an address type is a significant improvement. It enhances the flexibility and accuracy of the conversion process by correctly identifying and converting such library function calls. This change appears to be logically sound and correctly implemented.

coderabbitai · 2024-02-29T18:08:10Z

slither/core/declarations/function.py

+        reentrancy_modifier = "nonReentrant"
+
+        if self.function_language == FunctionLanguage.Vyper:
+            reentrancy_modifier = "nonreentrant(lock)"
+


The introduction of a Vyper-specific reentrancy modifier ("nonreentrant(lock)") is a significant enhancement for supporting Vyper smart contracts. However, it's important to ensure that this modifier name aligns with the latest Vyper conventions and syntax. Additionally, consider externalizing these modifier names into a configuration or constants file to facilitate easier updates and maintenance.

coderabbitai · 2024-02-29T18:08:10Z

slither/core/declarations/function.py

        ]
        if not all_entry_points:
            return True
-        return not all(("nonReentrant" in [m.name for m in f.modifiers] for f in all_entry_points))
+        return not all(
+            (reentrancy_modifier in [m.name for m in f.modifiers] for f in all_entry_points)
+        )

    # endregion
    ###################################################################################


📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1509-1523]

The logic for determining if a function is reentrant based on the presence of a reentrancy modifier and the function's visibility is sound. However, this approach assumes that all public and external functions without the specified reentrancy modifier are potentially reentrant. While this is a safe assumption, it might be beneficial to document this explicitly in the method's comments for clarity. Additionally, the use of list comprehensions inside the all() function call in line 1522 seems incorrect and could lead to a syntax error. It should be a generator expression or a list of boolean values.

- (reentrancy_modifier in [m.name for m in f.modifiers] for f in all_entry_points) + [reentrancy_modifier in [m.name for m in f.modifiers] for f in all_entry_points]

coderabbitai · 2024-02-29T18:08:10Z

slither/tools/flattening/flattening.py


        self._get_source_code_top_level(compilation_unit.structures_top_level)
        self._get_source_code_top_level(compilation_unit.enums_top_level)
+        self._get_source_code_top_level(compilation_unit.events_top_level)
        self._get_source_code_top_level(compilation_unit.custom_errors)
        self._get_source_code_top_level(compilation_unit.variables_top_level)
        self._get_source_code_top_level(compilation_unit.functions_top_level)


📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-255]

Overall, the Flattening class and its methods appear to be well-structured and logically organized. The code is generally clean and follows Python best practices. However, there are a few areas where improvements could be made for better maintainability and readability:

Error Handling: The method _get_source_code uses raise SlitherException in multiple places for error handling (e.g., when keywords are not found). It's important to ensure that these exceptions are caught and handled gracefully where _get_source_code is called, to avoid unexpected crashes of the tool. Consider adding documentation on the expected exceptions for each method or implementing a more comprehensive error handling strategy.

Performance Considerations: In methods like _export_list_used_contracts, there's potential for optimization. For example, converting lists to sets for operations that involve membership testing could improve performance, as set operations are generally faster than list operations for these cases.

Documentation: While the code is quite readable, adding more in-line comments explaining the purpose of complex sections or logic would enhance maintainability. For instance, the patching logic in _get_source_code could benefit from additional comments explaining the rationale behind each patch type.

Refactoring Opportunities: The method _get_source_code is quite long and handles multiple responsibilities, from patching source code to handling different visibility modifiers. Consider refactoring this method into smaller, more focused methods. This would not only improve readability but also make the code easier to maintain and test.

Testing: There's no direct indication of tests for the new changes or the Flattening class itself. Ensuring comprehensive unit tests for all methods, especially those involving complex logic like _get_source_code, is crucial for maintaining the reliability of the tool. Consider adding tests that cover various scenarios, including edge cases.

# Suggested improvements for documentation and refactoring: # Example for adding more in-line comments and refactoring a complex method into smaller parts. def _get_source_code(self, contract: Contract): """ Save the source code of the contract in self._source_codes and patch the source code. This involves adjusting visibility modifiers and handling specific Solidity patterns. :param contract: The contract whose source code is to be processed. :return: None """ # Initial setup and source code retrieval src_mapping, content, start, end = self._prepare_source_code(contract) # Determine patches to apply based on contract properties to_patch = self._determine_patches(contract, content, start, end) # Apply patches to the source code self._apply_patches(content, start, end, to_patch) # Store the patched source code self._source_codes[contract] = content # This is just an illustrative example. The actual implementation would need to define # _prepare_source_code, _determine_patches, and _apply_patches methods.

coderabbitai · 2024-02-29T18:08:10Z

slither/solc_parsing/yul/evm_functions.py

@@ -199,6 +210,7 @@
    "extcodecopy": [4, 0],
    "returndatasize": [0, 1],
    "returndatacopy": [3, 0],
+    "mcopy": [3, 0],


The addition of MCOPY to the function_args dictionary with the correct stack requirements is noted. However, it's important to ensure that MCOPY is also added to the evm_opcodes list if it's intended to be recognized as a valid opcode.

+ "MCOPY",

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change

"mcopy": [3, 0],

"mcopy": [3, 0],

"MCOPY",

coderabbitai · 2024-02-29T18:08:10Z

tests/e2e/detectors/test_data/constable-states/0.8.0/const_state_variables.sol

@@ -66,13 +66,18 @@ contract Good {
    uint immutable should_be_immutable_3 = 10 + block.number;
    B immutable should_be_immutable_4 = new B();
    uint immutable should_be_immutable_5;
-
+    uint blobBaseFee;


The addition of the blobBaseFee state variable is straightforward and follows Solidity conventions for declaring state variables. However, it's important to ensure that the visibility of blobBaseFee aligns with the intended use case. If external contracts or accounts should not directly modify it, consider marking it as private or internal.

- uint blobBaseFee; + uint private blobBaseFee;

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change

uint blobBaseFee;

uint private blobBaseFee;

coderabbitai · 2024-02-29T18:08:11Z

tests/e2e/detectors/test_data/out-of-order-retryable/0.8.20/out_of_order_retryable.sol

+function bad4() external {
+     good2();
+     good2();
+}


The function bad4 calls good2() twice consecutively without any checks or differentiating logic. This might be intentional for demonstration but could be seen as redundant or potentially wasteful in terms of gas if good2 performs significant operations. Consider documenting the intent clearly.

- good2(); - good2(); + // Calling good2 twice for demonstration

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change

function bad4() external {

good2();

good2();

}

function bad4() external {

// Calling good2 twice for demonstration

}

coderabbitai · 2024-02-29T18:08:11Z

examples/scripts/data_dependency.sol

+contract SimpleModifier {
+    address owner;
+    modifier baz {
+        bool intermediate = msg.sender == owner;
+        require(intermediate);
+        _;
+    }


The SimpleModifier contract introduces a baz modifier to check if msg.sender is the owner. This is a common pattern for access control. However, the owner variable is declared but not initialized, which means it will default to the zero address. Ensure that the owner is correctly initialized, typically in the constructor, to prevent unauthorized access.

contract SimpleModifier { address owner; + constructor() { + owner = msg.sender; + } modifier baz { bool intermediate = msg.sender == owner; require(intermediate); _; } }

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change

contract SimpleModifier {

address owner;

modifier baz {

bool intermediate = msg.sender == owner;

require(intermediate);

_;

}

contract SimpleModifier {

address owner;

constructor() {

owner = msg.sender;

}

modifier baz {

bool intermediate = msg.sender == owner;

require(intermediate);

_;

}

}

coderabbitai · 2024-02-29T18:08:11Z

slither/core/declarations/contract.py

        """
        return list(self._variables.values())

+    @property
+    def stored_state_variables(self) -> List["StateVariable"]:
+        """
+        Returns state variables with storage locations, excluding private variables from inherited contracts.
+        Use stored_state_variables_ordered to access variables with storage locations in their declaration order.
+
+        This implementation filters out state variables if they are constant or immutable. It will be
+        updated to accommodate any new non-storage keywords that might replace 'constant' and 'immutable' in the future.
+
+        Returns:
+            List[StateVariable]: A list of state variables with storage locations.
+        """
+        return [variable for variable in self.state_variables if variable.is_stored]
+
+    @property
+    def stored_state_variables_ordered(self) -> List["StateVariable"]:
+        """
+        list(StateVariable): List of the state variables with storage locations by order of declaration.
+
+        This implementation filters out state variables if they are constant or immutable. It will be
+        updated to accommodate any new non-storage keywords that might replace 'constant' and 'immutable' in the future.
+
+        Returns:
+            List[StateVariable]: A list of state variables with storage locations ordered by declaration.
+        """
+        return [variable for variable in self.state_variables_ordered if variable.is_stored]
+
    @property
    def state_variables_entry_points(self) -> List["StateVariable"]:
        """


📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [1-464]

Throughout the Contract class, there is consistent use of type annotations, which enhances code readability and maintainability. The organization of the class into regions for different categories of methods and properties is a good practice, making the large class more navigable. However, the class is quite large, which could impact maintainability. Consider refactoring into smaller, more focused classes or modules if possible to improve modularity and ease of understanding.

Consider breaking down the Contract class into smaller, more focused classes or modules to improve maintainability and modularity. This could involve separating functionality related to event handling, state variable management, and inheritance into distinct classes or modules.

coderabbitai · 2024-02-29T18:08:11Z

slither/tools/mutator/mutators/MWA.py

+class MWA(AbstractMutator):  # pylint: disable=too-few-public-methods
+    NAME = "MWA"
+    HELP = '"while" construct around statement'
+
+    def _mutate(self) -> Dict:
+        result: Dict = {}
+
+        for function in self.contract.functions_and_modifiers_declared:
+            for node in function.nodes:
+                if node.type == NodeType.IFLOOP:
+                    # Get the string
+                    start = node.source_mapping.start
+                    stop = start + node.source_mapping.length
+                    old_str = self.in_file_str[start:stop]
+                    line_no = node.source_mapping.lines
+                    if not line_no[0] in self.dont_mutate_line:
+                        if not isinstance(node.expression, UnaryOperation):
+                            new_str = str(UnaryOperationType.BANG) + "(" + old_str + ")"
+                            create_patch_with_line(
+                                result,
+                                self.in_file,
+                                start,
+                                stop,
+                                old_str,
+                                new_str,
+                                line_no[0],
+                            )
+        return result


The implementation of the "while" construct mutator (MWA) seems to be targeting IFLOOP nodes. However, the mutation logic appears to be adding a negation (!) to the condition rather than wrapping the statement in a "while" construct. Ensure that the mutation logic aligns with the intended behavior described by the HELP attribute.

- if not isinstance(node.expression, UnaryOperation): - new_str = str(UnaryOperationType.BANG) + "(" + old_str + ")" + # Assuming the intended mutation is to wrap the statement in a while loop + new_str = "while (" + old_str + ") {}"

Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change

class MWA(AbstractMutator): # pylint: disable=too-few-public-methods

NAME = "MWA"

HELP = '"while" construct around statement'

def _mutate(self) -> Dict:

result: Dict = {}

for function in self.contract.functions_and_modifiers_declared:

for node in function.nodes:

if node.type == NodeType.IFLOOP:

# Get the string

start = node.source_mapping.start

stop = start + node.source_mapping.length

old_str = self.in_file_str[start:stop]

line_no = node.source_mapping.lines

if not line_no[0] in self.dont_mutate_line:

if not isinstance(node.expression, UnaryOperation):

new_str = str(UnaryOperationType.BANG) + "(" + old_str + ")"

create_patch_with_line(

result,

self.in_file,

start,

stop,

old_str,

new_str,

line_no[0],

)

return result

class MWA(AbstractMutator): # pylint: disable=too-few-public-methods

NAME = "MWA"

HELP = '"while" construct around statement'

def _mutate(self) -> Dict:

result: Dict = {}

for function in self.contract.functions_and_modifiers_declared:

for node in function.nodes:

if node.type == NodeType.IFLOOP:

# Get the string

start = node.source_mapping.start

stop = start + node.source_mapping.length

old_str = self.in_file_str[start:stop]

line_no = node.source_mapping.lines

if not line_no[0] in self.dont_mutate_line:

# Assuming the intended mutation is to wrap the statement in a while loop

new_str = "while (" + old_str + ") {}"

create_patch_with_line(

result,

self.in_file,

start,

stop,

old_str,

new_str,

line_no[0],

)

return result

coderabbitai · 2024-02-29T18:08:12Z

tests/e2e/detectors/test_data/suicidal/0.7.6/suicidal.sol

+    function i_am_a_backdoor2(address payable to) public{
+        internal_selfdestruct(to);
+    }
+
+    function internal_selfdestruct(address payable to) internal {
+        selfdestruct(to);
+    }


The addition of i_am_a_backdoor2 and internal_selfdestruct functions in contract C is correctly implemented for self-destructing the contract. However, allowing arbitrary self-destruction poses a significant security risk and should be used with extreme caution, if at all.

Consider restricting access to these functions using modifiers to ensure only authorized users can trigger self-destruction.

0xalpharush and others added 30 commits October 18, 2023 14:07

Update Dockerfile

cd3f2d4

remove unused files

ea708cd

Update installation instrucitons

8d9199e

Update README.md

112786f

added update reachability to modifiers

c1a1675

Update modifier.py

0994edf

removed trailing whitespace

Merge pull request #2198 from VIELITE/master

2940d26

Update README.md

Merge pull request #2189 from crytic/0xalpharush-patch-2

78ba65b

Update installation instrucitons

Merge pull request #2188 from crytic/0xalpharush-patch-1

c311054

Update Dockerfile

Merge pull request #2199 from crytic/dependabot/github_actions/dev/ac…

fbd578a

…tions/setup-node-4 Bump actions/setup-node from 3 to 4

fix is_reentrant for internal vyper functions

b7ba2c4

Add support top level events

4a33541

Error when a missing contract is specified to read-storage. Previousl…

912d6b2

…y this just silently exited

Merge pull request #2235 from UsmannK/usmannk/add-missing-contract-error

456a414

Raise an error when a missing contract is specified to read-storage

Don't report if msg.value is in a conditional expression

a793c3f

Merge pull request #2252 from crytic/dependabot/github_actions/dev/ca…

e5d2927

…chix/install-nix-action-24 Bump cachix/install-nix-action from 23 to 24

Merge pull request #2253 from crytic/dependabot/github_actions/dev/ac…

de29c2a

…tions/configure-pages-4 Bump actions/configure-pages from 3 to 4

Merge pull request #2254 from crytic/dependabot/github_actions/dev/ac…

05310b4

…tions/deploy-pages-3 Bump actions/deploy-pages from 2 to 3

Merge pull request #2255 from crytic/dependabot/github_actions/dev/py…

b8456eb

…pa/gh-action-pypi-publish-1.8.11 Bump pypa/gh-action-pypi-publish from 1.8.10 to 1.8.11

Merge pull request #2197 from crytic/remove-unused-files

3e62ea6

remove unused files

Merge pull request #2211 from crytic/fix-vyper-is-reentrant

deebe36

fix is_reentrant for internal vyper functions

Substituted the letter 'z' with 'x' in pre-declaration

ff0e85d

Merge pull request #2258 from ATREAY/docs

40536d8

Substituted the letter `z` with `x` in pre-declaration

updated mutator

a036598

Updated replace string logic

37c23e1

0xalpharush and others added 24 commits February 19, 2024 22:06

add regression test for #2313

052a30a

Delete file

47fdb81

remove unnecessary use of list comprehension

a99f90b

Merge pull request #2323 from dokzai/issue-1644

9c868e7

Create a variable API that filters out constants and immutables

Merge pull request #2321 from crytic/test/modifier-data-dependency

fc244e4

add regression test for #2313

Merge pull request #2281 from crytic/dev-solidity-0.8.24

4580844

Add support Solidity 0.8.24

Merge pull request #2320 from crytic/fix/inheritance-renaming

942adb1

fix: support renaming in base inheritance and base constructor calls

Merge pull request #2239 from crytic/dev-msgvalue-loop-fps

dc2c8cb

msg-value-loop: Don't report if msg.value is in a conditional expression

Merge pull request #2315 from crytic/dev-shift-mixup

5d140f7

incorrect-shift: Detect only assembly blocks

Track storage variables read/written in assembly

d592e76

Add --include-paths option

a9163d2

Lint

c0d4dde

Merge pull request #2146 from crytic/dependabot/github_actions/dev/do…

a844f2d

…cker/metadata-action-5 Bump docker/metadata-action from 4 to 5

fix: support inheritance resolution when contract name is reused

665b630

feat: add out-of-order-retryable ticket detector

69d3c25

make it interprocedural (only 1 call deep)

04ff85f

add test showing two internal call example is caught

75c1159

Merge pull request #2332 from crytic/fix/inheritance-resolving-duplic…

23c4cce

…ate-names fix: support inheritance resolution when contract name is reused

add regression test for #2325

801a13e

Merge pull request #2340 from crytic/feat/out-of-order-retryable-dete…

1854c14

…ctor Feat/out of order retryable detector

Merge pull request #2329 from crytic/dev-constant-yul

754d64d

Track storage variables read/written in assembly

update --inlude-paths help

a8915a8

Merge pull request #2330 from crytic/dev-include-paths

a8dc50e

Add --include-paths option

0xalpharush requested review from elopez, montyly and smonicas as code owners February 29, 2024 17:58

coderabbitai bot reviewed Feb 29, 2024

View reviewed changes

0xalpharush merged commit ecc7a4f into master Feb 29, 2024
229 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

sync master<>dev #2341

sync master<>dev #2341

0xalpharush commented Feb 29, 2024 •

edited

Loading

coderabbitai bot commented Feb 29, 2024 •

edited

Loading

Chat

CodeRabbit Commands (invoked as PR comments)

CodeRabbit Configration File (`.coderabbit.yaml`)

CodeRabbit Discord Community

coderabbitai bot left a comment

coderabbitai bot Feb 29, 2024

coderabbitai bot Feb 29, 2024

coderabbitai bot Feb 29, 2024

coderabbitai bot Feb 29, 2024

coderabbitai bot Feb 29, 2024

coderabbitai bot Feb 29, 2024

coderabbitai bot Feb 29, 2024

coderabbitai bot Feb 29, 2024

coderabbitai bot Feb 29, 2024

coderabbitai bot Feb 29, 2024

sync master<>dev #2341

sync master<>dev #2341

Conversation

0xalpharush commented Feb 29, 2024 • edited Loading

coderabbitai bot commented Feb 29, 2024 • edited Loading

Walkthrough

Changes

Poem

Chat

CodeRabbit Commands (invoked as PR comments)

CodeRabbit Configration File (.coderabbit.yaml)

CodeRabbit Discord Community

coderabbitai bot left a comment

Choose a reason for hiding this comment

coderabbitai bot Feb 29, 2024

Choose a reason for hiding this comment

coderabbitai bot Feb 29, 2024

Choose a reason for hiding this comment

coderabbitai bot Feb 29, 2024

Choose a reason for hiding this comment

coderabbitai bot Feb 29, 2024

Choose a reason for hiding this comment

coderabbitai bot Feb 29, 2024

Choose a reason for hiding this comment

coderabbitai bot Feb 29, 2024

Choose a reason for hiding this comment

coderabbitai bot Feb 29, 2024

Choose a reason for hiding this comment

coderabbitai bot Feb 29, 2024

Choose a reason for hiding this comment

coderabbitai bot Feb 29, 2024

Choose a reason for hiding this comment

coderabbitai bot Feb 29, 2024

Choose a reason for hiding this comment

0xalpharush commented Feb 29, 2024 •

edited

Loading

coderabbitai bot commented Feb 29, 2024 •

edited

Loading

CodeRabbit Configration File (`.coderabbit.yaml`)