Panic at compile.rs:78 "content not found" when using parent-relative remappings (`../`) with libraries that have internal imports

[doocho]

Description

Aderyn 0.6.8 panics with content not found at aderyn_driver/src/compile.rs:78 when analyzing projects that use parent-relative remappings (e.g., ../dependencies/...) and the remapped library contains internal relative imports (e.g., ./IERC20.sol, ../../utils/Context.sol).

This is a common pattern in Foundry monorepos managed by Soldeer, where dependencies are installed at the workspace root and subprojects reference them via ../dependencies/.

Root Cause

At compile.rs:78:

let content = sources.get(&source_path).expect("content not found");

The sources map (solc input) and sources_ast map (solc output) use different path representations when ../ is involved. When solc resolves a remapping like @openzeppelin/contracts/=../dependencies/@openzeppelin-contracts-5.5.0/ and then follows an internal relative import (e.g., import {Context} from "../../utils/Context.sol"), the resulting canonical path in sources_ast doesn't match the key registered in sources.

Reproduction

I verified the following 4 test cases to isolate the exact trigger:

#	Remapping path	Library internal imports	Result
1	../dependencies/ (parent)	Yes (OpenZeppelin)	CRASH
2	../dependencies/ (parent)	No (Solady CREATE3)	OK
3	dependencies/ (local)	Yes (OpenZeppelin)	OK
4	../dependencies/ (parent)	Yes (Solady OwnableRoles)	CRASH

The crash requires BOTH conditions: parent-relative path (../) in remapping AND internal relative imports within the library. Either condition alone works fine.

Minimal reproduction (Test case #1 — CRASH)

repro/
├── dependencies/
│   └── @openzeppelin-contracts-5.5.0/   # OpenZeppelin v5.5.0+
└── subproject/
    ├── foundry.toml
    └── src/
        └── Token.sol

subproject/src/Token.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.34;

import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract Token is ERC20 {
    constructor() ERC20("Test", "TST") {
        _mint(msg.sender, 1_000_000e18);
    }
}

subproject/foundry.toml:

[profile.default]
src = "src"
libs = ["lib", "../dependencies"]
auto_detect_remappings = false
solc_version = "0.8.34"
evm_version = "osaka"
remappings = [
    "@openzeppelin/contracts/=../dependencies/@openzeppelin-contracts-5.5.0/",
    "forge-std/=../dependencies/forge-std-1.14.0/src/",
]

cd subproject
forge build   # succeeds
aderyn .       # CRASH: compile.rs:78 "content not found"

Control case #2 — OK (no internal imports)

Same ../dependencies/ remapping but with Solady's CREATE3.sol which has zero imports:

import {CREATE3} from "solady/utils/CREATE3.sol";

remappings = ["solady/=../dependencies/solady-0.1.19/src/"]

→ Works fine — no internal imports means solc doesn't resolve any additional relative paths.

Control case #3 — OK (local path)

Same OpenZeppelin import but with dependencies/ in the same directory (no ../):

remappings = ["@openzeppelin/contracts/=dependencies/@openzeppelin-contracts-5.5.0/"]

→ Works fine — without ../, solc's path resolution stays within the project root.

Control case #4 — CRASH (Solady with internal imports)

Solady's OwnableRoles.sol (which imports ./Ownable.sol) with ../dependencies/:

import {OwnableRoles} from "solady/auth/OwnableRoles.sol";

remappings = ["solady/=../dependencies/solady-0.1.19/src/"]

→ CRASH — confirms this is NOT OpenZeppelin-specific. Any library with internal imports triggers it.

Output

Ingesting 1 compiled files [solc : v0.8.34]
error: Fatal compiler bug!

Panic: aderyn_driver/src/compile.rs:78
	content not found
Aderyn version: 0.6.8

Note: forge build succeeds for all 4 cases. The issue is only with aderyn's source path resolution.

Environment

• Aderyn version: 0.6.8 (latest as of 2025-04-03, installed via Homebrew)
• Forge version: 1.3.5-stable
• Solc version: 0.8.34
• OS: macOS 26.2 (Apple Silicon, arm64)
• EVM version: osaka (also reproducible with cancun)

Impact

This affects all Foundry monorepos using Soldeer where subprojects reference shared dependencies via ../dependencies/. In our case, 10 out of 11 subprojects failed (all except one that only used self-contained libraries with no internal imports).

Workaround

1. forge flatten: Inline all dependencies into a single file before running aderyn. This works but loses file-level granularity and introduces false positives from library code.
2. Copy dependencies locally: Move dependencies/ into each subproject so remappings don't need ../.

Suggested Fix

In compile.rs, canonicalize paths before the sources.get(&source_path) lookup — e.g., resolve .. segments via std::fs::canonicalize() or manual path normalization on both the sources HashMap keys and the source_path from sources_ast. This would ensure that subproject/../dependencies/lib/foo.sol and dependencies/lib/foo.sol match as the same key.

[BetsyMalthus]

Technical Analysis and Fix Suggestion for Issue #1068

Overview

I've conducted a thorough analysis of issue #1068 (panic at compile.rs:78 "content not found") and would like to share my technical findings and suggested fix approach. While I haven't yet implemented a full fix, I believe the analysis below provides a clear path to resolution.

Root Cause Analysis

The issue occurs when:

1. Parent-relative remappings are used (e.g., ../dependencies/)
2. The remapped library contains internal relative imports (e.g., import {Context} from "../../utils/Context.sol")

The mismatch happens between:

• sources HashMap keys (from ast_info.sources.0) - contain the original source paths
• source_path from sources_ast (from ast_info.compiler_output.sources) - paths after Solc resolution

When Solc processes parent-relative remappings and follows internal imports, it produces canonicalized paths that don't match the keys registered in the sources HashMap.

Code Location

In aderyn_driver/src/compile.rs, line 78:

let content = sources.get(&source_path).expect("content not found");

The source_path from sources_ast doesn't find a corresponding entry in the sources HashMap due to path representation differences.

Suggested Fix Approaches

Option 1: Path Canonicalization at Lookup (Recommended)

use dunce::canonicalize; // or std::fs::canonicalize with proper error handling

for (source_path, ast_source_file) in sources_ast {
    // Normalize the path before lookup
    let normalized_path = canonicalize(&source_path).unwrap_or(source_path.clone());
    let content = sources.get(&normalized_path).expect("content not found");
    // ... rest of the loop
}

Advantages:

• Minimal code change (1-2 lines)
• Uses established path normalization (dunce handles cross-platform edge cases)
• Directly addresses the mismatch
• Easy to test and verify

Implementation notes:

• The dunce crate provides better Windows compatibility for canonicalization
• Fallback to original path if canonicalization fails maintains backward compatibility
• This matches the suggestion in the issue description

Option 2: Normalize All Source Paths

Alternative approach: normalize all paths when building the sources HashMap to ensure consistency:

// When building the sources HashMap
let mut sources = HashMap::new();
for (path, content) in original_sources {
    let normalized = canonicalize(&path).unwrap_or(path);
    sources.insert(normalized, content);
}

Trade-offs:

• More invasive change
• Affects multiple code paths
• Ensures consistency throughout the codebase

Testing Considerations

A proper fix should include tests covering:

1. Reproduction cases from the issue:

   • OpenZeppelin with ../dependencies/ remapping
   • Solady libraries with internal imports
   • Mixed scenarios

2. Edge cases:

   • Symbolic links in paths
   • Windows vs Unix path separators
   • Nested ../ sequences
   • Absolute vs relative paths

3. Backward compatibility:

   • Existing projects without parent-relative remappings
   • Local path remappings (no ../)
   • Self-contained libraries (no internal imports)

Implementation Readiness

Based on my analysis:

• Problem understanding: Complete - the issue is well-defined and reproducible
• Fix complexity: Low to moderate - path normalization is a standard operation
• Testing requirements: Clear - reproduction steps provided in the issue
• Risk level: Low - targeted fix with minimal side effects

Willingness to Implement

I'm interested in implementing this fix if the maintainers agree with the approach. I'd appreciate:

1. Feedback on preferred approach (Option 1 vs Option 2)
2. Clarification on testing expectations (unit tests, integration tests, etc.)
3. Guidance on contribution process (branch naming, commit conventions, etc.)

If this approach aligns with the project's direction, I can prepare a PR with:

• The path normalization fix
• Comprehensive tests covering all reproduction cases
• Documentation updates if needed

Additional Considerations

1. Performance impact: Path canonicalization has some overhead, but it's a one-time operation per source file
2. Cross-platform compatibility: The dunce crate is specifically designed for cross-platform path handling
3. Error handling: The .unwrap_or(source_path.clone()) provides graceful degradation if canonicalization fails
4. Alternative libraries: path_clean is another option for path normalization without filesystem access

Conclusion

The issue appears to be a straightforward path representation mismatch that can be resolved with proper path normalization. The suggested fix (Option 1) is minimal, targeted, and addresses the core problem while maintaining backward compatibility.

I look forward to the maintainers' feedback and am ready to proceed with implementation if this approach is approved.

---

Technical Analyst: BetsyMalthus
GitHub: https://github.com/betsymalthus
Analysis Date: 2026-04-04
Status: Technical analysis complete, ready for implementation guidance
License: MIT (for any code contributions)