Foundry/main

[Dargon789]

Motivation

Solution

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

Summary by Sourcery

Introduce new linting infrastructure and example counter project while tightening filesystem handling and adding extensive CI/CD and security scanning workflows.

New Features:

• Add a generic linting framework with early AST-based lint passes for smart contract languages.
• Add a sample counter Foundry project with contract, script, tests, and project configuration.
• Include Remix-compatible Solidity testing helpers and assertion libraries as project dependencies.

Bug Fixes:

• Harden temporary project cleanup and script file copying against path traversal and symlink-based directory escape issues.
• Always run the preprocessed contract decode-internal-functions optimizer test by removing its feature gate.

Enhancements:

• Add the alloy-hardforks workspace dependency to the Forge crate.
• Provide a reusable lint context helper to emit diagnostics with configurable descriptions from lint passes.

Build:

• Add multiple GitHub Actions workflows for building, testing, Docker image creation, deployment, CodeQL analysis, API security scans, and Snyk container scanning.
• Add CircleCI configurations for Rust formatting, testing, and example web3/game-related jobs.

CI:

• Set up dedicated CI workflows for the example counter project using Foundry tooling and for various Docker build and signing pipelines.

Documentation:

• Add README and issue templates for bug reports, feature requests, and custom issues describing project usage and contribution expectations.

Tests:

• Add unit and fuzz tests for the sample counter contract to validate basic behavior and integration with Forge.

[codesandbox]

Review or Edit in CodeSandbox

Open the branch in Web Editor • VS Code • Insiders

Open Preview

[sourcery-ai]

Reviewer's Guide

Adds security-hardened file handling in benchmarks and test utilities, introduces a generic linting abstraction over the Solar AST, adjusts forge dependencies/tests, and brings in a large set of CI/workflow, issue-template, and example counter project artifacts (including Remix test libs) into the repo.

File-Level Changes

Change	Details	Files
Harden temporary project and script file handling against path traversal and unsafe deletions.	BenchmarkProject cleanup now canonicalizes entries, verifies they remain under the temp root, logs and skips suspicious paths, and deletes via canonical paths. ScriptTester copy logic now rejects filenames with traversal or separator characters and skips files whose canonical paths escape the source directory.	benches/src/lib.rs crates/test-utils/src/script.rs
Introduce a generic linting framework over Solar AST to support language-agnostic lints.	Define a Linter trait parameterized by language and lint type, plus a Lint trait describing id, severity, description, and help. Add LintContext to simplify emitting diagnostics via solar_interface with optional descriptions. Define EarlyLintPass and EarlyLintVisitor that hook into solar_ast::visit::Visit to run lint passes over expressions, structs, functions, and variable definitions.	crates/lint/src/linter.rs
Adjust forge crate dependencies and tests for new functionality.	Add alloy-hardforks as a workspace dependency to forge. Enable preprocess_contract_with_decode_internal test unconditionally by removing the isolate-by-default cfg gate.	crates/forge/Cargo.toml crates/forge/tests/cli/test_optimizer.rs
Vendor Remix testing helpers into a .deps directory for Solidity-based tests.	Add Remix-style Assert library for rich assertion events across multiple Solidity types. Add TestsAccounts helper library with a fixed set of test account addresses.	.deps/remix-tests/remix_tests.sol .deps/remix-tests/remix_accounts.sol
Add a sample Foundry counter project (with config, contracts, script, tests, and README).	Introduce a minimal Counter contract with setNumber and increment methods. Add Forge script and tests for deploying and exercising Counter, plus Foundry config, gitignore, and library submodules. Document basic Foundry usage in a dedicated counter/README.md.	counter/src/Counter.sol counter/script/Counter.s.sol counter/test/Counter.t.sol counter/foundry.toml counter/README.md counter/.gitignore counter/lib/forge-std counter/lib/openzeppelin-contracts
Introduce multiple CI pipelines and security scanning workflows for Docker, GKE deploys, Snyk, CodeQL, APIsec, and CircleCI.	Add GitHub Actions workflows for Docker builds, container publishing, GKE deploy, CodeQL analysis, Snyk container scans, APIsec scans, and Foundry counter project CI. Add several CircleCI configs covering generic jobs, Rust build/test flows, and custom web3/gamefi-oriented executors. Add a basic deploy workflow that builds/tests with cargo and then builds a Docker image.	.github/workflows/docker.yml .github/workflows/docker-image.yml .github/workflows/google.yml .github/workflows/codeql.yml .github/workflows/snyk-container.yml .github/workflows/apisec-scan.yml .github/workflows/deploy.yml counter/.github/workflows/test.yml .circleci/config.yml .circleci/ci.yml .circleci/cargo.yml .circleci/ci_cargo.yml .circleci/ci-web3-gamefi.yml .circleci/web3_defi_gamefi.yml
Add standard GitHub issue templates to streamline bug reports and feature requests.	Provide structured bug report template capturing environment and reproduction steps. Provide feature request template and a placeholder custom template.	.github/ISSUE_TEMPLATE/bug_report.md .github/ISSUE_TEMPLATE/feature_request.md .github/ISSUE_TEMPLATE/custom.md
Introduce various repo metadata and placeholder files for tooling integration.	Add empty or placeholder files for CodeSandbox tasks, git submodules, and other tooling hooks.	.codesandbox/tasks.json .gitmodules

Possibly linked issues

• Foundry/ethereum ux (#284) #289 #290 #291: The PR delivers the AST keccak256 gas lint, new linting infra, CI/security workflows, and counter sample project requested.
• sign_with_access_key Tempo access-key signing  #585: The PR introduces the Tempo access-key signing flow and related infrastructure exactly matching the issue’s described changes.

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
next	Canceled		Jun 18, 2026 11:03am
react	Canceled		Jun 18, 2026 11:03am

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[gemini-code-assist]

Code Review

This pull request introduces several new CircleCI workflows, GitHub issue templates, a counter project, and a new linter framework. It also implements path canonicalization and validation in benchmark cleanup and test-utils scripts to prevent directory traversal. Feedback highlights potential issues with path prefix checks on systems with symlinks due to uncanonicalized base paths, redundant duplicate steps in CircleCI configurations, hardcoded user fork URLs in CI files, and an unused import in suggestions.rs that could trigger compiler warnings.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[sourcery-ai]

Hey - I've found 8 issues, and left some high level feedback:

• The .github/workflows/docker.yml workflow is syntactically invalid (e.g., runs-on and permissions are outside the build job and there is a stray jobs.build block at the top); please restructure it so each job has the expected runs-on and steps keys in the right place.
• In .github/workflows/google.yml, the branch filters are written as "main" / "master" (with embedded quotes), which will not match actual branch names; these should be plain main / master strings.
• There are multiple overlapping CI configs (several CircleCI files plus several Docker-related GitHub Actions workflows) that appear redundant or sample-based; consider consolidating or removing unused ones to avoid confusion and maintenance overhead.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `.github/workflows/docker.yml` workflow is syntactically invalid (e.g., `runs-on` and `permissions` are outside the `build` job and there is a stray `jobs.build` block at the top); please restructure it so each job has the expected `runs-on` and `steps` keys in the right place.
- In `.github/workflows/google.yml`, the branch filters are written as `"main"` / `"master"` (with embedded quotes), which will not match actual branch names; these should be plain `main` / `master` strings.
- There are multiple overlapping CI configs (several CircleCI files plus several Docker-related GitHub Actions workflows) that appear redundant or sample-based; consider consolidating or removing unused ones to avoid confusion and maintenance overhead.

## Individual Comments

### Comment 1
<location path="crates/lint/src/linter.rs" line_range="47-48" />
<code_context>
+        Self { sess, desc: with_description }
+    }
+
+    // Helper method to emit diagnostics easily from passes
+    pub fn emit<L: Lint>(&self, lint: &'static L, span: Span) {
+        let desc = if self.desc { lint.description() } else { "" };
+        let diag: DiagBuilder<'_, ()> = self
</code_context>
<issue_to_address>
**suggestion:** Requiring `&'static L` in `emit` makes it hard to use non-static lint instances.

Taking `lint: &'static L` unnecessarily requires all lints to be `'static`, so you can’t use lints created per run or that hold non-static configuration. Using `&L` instead (with the caller responsible for the lifetime) keeps the same safety for this call while making the API usable with more lint implementations.

```suggestion
    // Helper method to emit diagnostics easily from passes
    pub fn emit<L: Lint>(&self, lint: &L, span: Span) {
```
</issue_to_address>

### Comment 2
<location path="crates/lint/src/linter.rs" line_range="62-63" />
<code_context>
+    }
+}
+
+/// Trait for lints that operate directly on the AST.
+/// Its methods mirror `solar_ast::visit::Visit`, with the addition of `LintCotext`.
+pub trait EarlyLintPass<'ast>: Send + Sync {
+    fn check_expr(&mut self, _ctx: &LintContext<'_>, _expr: &'ast Expr<'ast>) {}
</code_context>
<issue_to_address>
**nitpick (typo):** Typo in `LintCotext` may cause confusion.

This should be `LintContext`. Even minor typos in type names can hinder searching and make the docs harder to scan.

```suggestion
/// Trait for lints that operate directly on the AST.
/// Its methods mirror `solar_ast::visit::Visit`, with the addition of `LintContext`.
```
</issue_to_address>

### Comment 3
<location path=".github/workflows/google.yml" line_range="105-107" />
<code_context>
+          docker push "${DOCKER_TAG}"
+
+      # Set up kustomize
+      - name: 'Set up Kustomize'
+        run: |-
+          curl -sfLo kustomize https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize%2Fv5.4.3/kustomize_v5.4.3_linux_amd64.tar.gz
+          chmod u+x ./kustomize
+
</code_context>
<issue_to_address>
**issue (bug_risk):** Kustomize is downloaded as a tar.gz but never extracted, so the binary is not usable.

The `curl -sfLo kustomize …tar.gz` command saves the compressed tarball as `kustomize` and then marks that tarball as executable, so `./kustomize` will fail. Instead, stream and extract the archive, then chmod the resulting binary, for example:

```bash
curl -sL https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize%2Fv5.4.3/kustomize_v5.4.3_linux_amd64.tar.gz \
  | tar xz
chmod u+x ./kustomize
```
</issue_to_address>

### Comment 4
<location path=".github/workflows/docker.yml" line_range="25-26" />
<code_context>
+version: 2.1
+#
+jobs:
+  build-and-test:
+    docker:
</code_context>
<issue_to_address>
**issue (bug_risk):** Workflow YAML structure is invalid: job `build` is missing `runs-on` and `steps` nesting is broken.

Here, `jobs.build` starts directly with a list item (e.g. `- name: Build the Docker image`) instead of defining `runs-on` and then a `steps:` list, and `runs-on` is indented as a sibling of `build`, making the YAML invalid and preventing the workflow from running. Please restructure to something like:

```yaml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Build the Docker image
        run: docker build …
      # other steps…
```
</issue_to_address>

### Comment 5
<location path=".github/workflows/deploy.yml" line_range="26-27" />
<code_context>
+      - name: Run tests
+        run: cargo test
+
+      - name: Docker build
+        run: docker build -t foundryg-rs
</code_context>
<issue_to_address>
**issue (bug_risk):** Docker build command is missing a build context (`.`), which will cause it to fail.

The `docker build` command needs a context argument or it will fail (`"docker build" requires exactly 1 argument`). If you’re building from the repo root, update to:

```yaml
run: docker build -t foundryg-rs .
```
</issue_to_address>

### Comment 6
<location path=".circleci/ci_cargo.yml" line_range="13-18" />
<code_context>
+          keys:
+            - v1-cargo-{{ checksum "Cargo.lock" }}
+            - v1-cargo-
+      - run:
+          name: "Check formatting"
+          command: cargo fmt -- --check
+      - run:
+          name: "Run tests"
+          command: cargo test
+      - save_cache:
+          key: v1-cargo-{{ checksum "Cargo.lock" }}
</code_context>
<issue_to_address>
**suggestion (performance):** Formatting and test steps are duplicated, doubling CI time without added benefit.

`cargo fmt -- --check` and `cargo test` are run twice in this job. Unless there’s a specific need for duplication, please remove the extra pair of steps to reduce CI time and resource usage while preserving behavior.
</issue_to_address>

### Comment 7
<location path="crates/test-utils/src/script.rs" line_range="126-132" />
<code_context>
         for entry in fs::read_dir(&from_dir)? {
             let file = &entry?.path();
             let name = file.file_name().unwrap();
+            // Validate file name to avoid path traversal and absolute paths
+            let name_str = name.to_string_lossy();
+            if name_str.contains("..") || name_str.contains("/") || name_str.contains("\\") {
+                // Skip invalid (potentially dangerous) file names
+                continue;
+            }
+            // Optionally verify canonicalized file is in from_dir to avoid symlink traversal
+            if let Ok(canonical_file) = file.canonicalize() {
+                if !canonical_file.starts_with(&from_dir) {
</code_context>
<issue_to_address>
**suggestion (testing):** Add tests for the new filename validation and symlink traversal checks in `ScriptTester`.

The new validation and symlink checks should be covered so changes don’t silently alter `ScriptTester` behavior. Please add tests that:

- Verify normal filenames (no `..`, `/`, `\`) are still copied.
- Verify filenames containing `..`, `/`, or `\` are skipped.
- Verify that when `canonicalize()` succeeds but the path escapes `from_dir` (e.g., via symlink), the file is skipped.
- Optionally, verify that a `canonicalize()` failure skips the entry without panicking.

This will lock in the security guarantees and clarify the intended behavior for consumers of `ScriptTester`.

Suggested implementation:

```rust
            // Verify canonicalized file is in from_dir to avoid symlink traversal.
            // If canonicalization fails (e.g. a broken symlink), skip the entry as well.
            match file.canonicalize() {
                Ok(canonical_file) => {
                    if !canonical_file.starts_with(&from_dir) {
                        // Skip files that resolve outside the source directory (symlink traversal).
                        continue;
                    }
                }
                Err(_) => {
                    // Skip entries we cannot canonicalize; treat them as unsafe.
                    continue;
                }
            }

```

You’ll also need to add tests around the `ScriptTester` code that uses this loop. Since I don’t see the rest of `script.rs`, you’ll need to adapt the examples to the actual API (e.g. the real method name on `ScriptTester` that triggers this copy logic). Below is a concrete outline you can drop into the existing `#[cfg(test)] mod tests` in `crates/test-utils/src/script.rs`:

1. **Helpers and imports**

Inside `mod tests`, make sure you have:

```rust
use super::*;
use std::fs;
use std::io::Write;
use std::path::Path;
use tempfile::tempdir;

// Helper to create a file with given content
fn write_file(dir: &Path, name: &str, contents: &str) {
    let path = dir.join(name);
    let mut f = fs::File::create(&path).unwrap();
    write!(f, "{}", contents).unwrap();
}
```

Adjust imports to match how `tempfile` or any temp-dir helper is already used elsewhere in your tests.

2. **Test: normal filenames are copied**

Assuming the copy logic is in a function like `copy_scripts(from_dir: &Path, to_dir: &Path) -> anyhow::Result<()>`
or a `ScriptTester` method like `tester.copy_scripts(&from_dir, &to_dir)`:

```rust
#[test]
fn copies_normal_filenames() {
    let from = tempdir().unwrap();
    let to = tempdir().unwrap();

    write_file(from.path(), "normal.txt", "ok");

    // Call into the real production function here:
    // copy_scripts(from.path(), to.path()).unwrap();
    // or:
    // let tester = ScriptTester::new(/* ... */);
    // tester.copy_scripts(from.path(), to.path()).unwrap();

    let copied = to.path().join("normal.txt");
    assert!(copied.exists(), "normal filename should be copied");
}
```

Replace the commented call with the actual `ScriptTester` API you have.

3. **Test: filenames containing `..`, `/`, or `\\` are skipped**

On Unix, you can create filenames containing `..` and `\\` directly; `/` is not allowed in a single filename, so for `/` you either:
- assert current behaviour only for `..` and `\\`, or
- create a subdirectory and assert that because only the basename is checked, it behaves as expected (if that’s what you want to lock in).

Example that locks in `..` and `\\` behaviour:

```rust
#[test]
fn skips_filenames_with_disallowed_components() {
    let from = tempdir().unwrap();
    let to = tempdir().unwrap();

    // This file name literally contains ".."
    write_file(from.path(), "..bad", "x");
    // This file name literally contains a backslash; on Unix it's just part of the name.
    write_file(from.path(), "evil\\file", "x");
    // Control file that should be copied
    write_file(from.path(), "good.txt", "ok");

    // Call into production copy logic
    // copy_scripts(from.path(), to.path()).unwrap();

    assert!(to.path().join("good.txt").exists(), "good.txt should be copied");
    assert!(!to.path().join("..bad").exists(), "..bad should be skipped");
    assert!(
        !to.path().join("evil\\file").exists(),
        "filenames containing backslash should be skipped"
    );
}
```

If you do want to test `/` explicitly on Windows, wrap that test in `#[cfg(windows)]` and create a name like `"dir/evil"` as appropriate for how your code is currently constructing `PathBuf`s.

4. **Test: symlink that escapes `from_dir` is skipped**

On Unix, you can use `std::os::unix::fs::symlink`:

```rust
#[cfg(unix)]
#[test]
fn skips_symlink_that_escapes_from_dir() {
    use std::os::unix::fs::symlink;

    let from = tempdir().unwrap();
    let to = tempdir().unwrap();
    let outside = tempdir().unwrap();

    // Real file outside from_dir
    write_file(outside.path(), "outside.txt", "secret");

    // Symlink inside from_dir pointing outside
    let link_path = from.path().join("link_to_outside");
    symlink(outside.path().join("outside.txt"), &link_path).unwrap();

    // Control file that should be copied
    write_file(from.path(), "inside.txt", "ok");

    // Call into production copy logic
    // copy_scripts(from.path(), to.path()).unwrap();

    assert!(to.path().join("inside.txt").exists(), "inside file should be copied");
    assert!(
        !to.path().join("link_to_outside").exists(),
        "symlink escaping from_dir should be skipped"
    );
}
```

On Windows, you can use `std::os::windows::fs::symlink_file` in a similar `#[cfg(windows)]` test.

5. **Test: canonicalize failure skips the entry**

Now that the code treats `canonicalize()` errors as “unsafe” and skips them, you can use a broken symlink to trigger a failure:

```rust
#[cfg(unix)]
#[test]
fn skips_entries_when_canonicalize_fails() {
    use std::os::unix::fs::symlink;

    let from = tempdir().unwrap();
    let to = tempdir().unwrap();

    // Broken symlink – target does not exist, so canonicalize() will fail.
    let broken_link = from.path().join("broken");
    symlink(from.path().join("nonexistent_target"), &broken_link).unwrap();

    // Control file that should be copied
    write_file(from.path(), "inside.txt", "ok");

    // Call into production copy logic
    // copy_scripts(from.path(), to.path()).unwrap();

    assert!(to.path().join("inside.txt").exists(), "inside file should be copied");
    assert!(
        !to.path().join("broken").exists(),
        "broken symlink should be skipped when canonicalize fails"
    );
}
```

If you want Windows coverage, add the analogous `#[cfg(windows)]` version that uses `std::os::windows::fs::symlink_file`.

**Important integration steps:**
- Replace the commented `copy_scripts(...)` / `ScriptTester::...` calls with the real function/method that runs the `for entry in fs::read_dir(&from_dir)?` loop you showed.
- If `ScriptTester` wraps temp directories internally, you may need to expose a helper (e.g., `fn copy_from_to(from: &Path, to: &Path)`) that the tests can call or create a `ScriptTester` instance in each test and drive it in the same way your existing tests do.
- Ensure `tempfile` is available in `[dev-dependencies]` of your crate, or re-use any existing temp-dir utility already used in `script.rs` tests.

These tests will lock in:
- copying of normal filenames,
- skipping of filenames with `..` or `\\`,
- skipping of symlinks that escape `from_dir`, and
- skipping entries where `canonicalize()` fails, without panicking.
</issue_to_address>

### Comment 8
<location path=".github/ISSUE_TEMPLATE/bug_report.md" line_range="27" />
<code_context>
+
+**Desktop (please complete the following information):**
+ - OS: [e.g. iOS]
+ - Browser [e.g. Chrome, safari]
+ - Version [e.g. 22]
+
</code_context>
<issue_to_address>
**suggestion (typo):** Capitalize "Safari" to match the proper noun and keep consistency with other occurrences.

Here, update `safari` to `Safari` as well.

```suggestion
 - OS: [e.g. iOS]
 - Browser [e.g. Chrome, Safari]
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}