generate go bindings in one package per contract/library #270
Conversation
WalkthroughThe pull request introduces significant changes to multiple Go packages related to Ethereum smart contracts. Key updates include renaming packages to better reflect their functionality, restructuring bindings for various contracts, and enhancing the generation of Go bindings from ABI files. The Changes
Possibly related PRs
Suggested labels
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (8)
bindings/go/ibceventsemitter/IbcEventsEmitter.go (3)
Line range hint
65-65: Ensure variable naming consistencyThe variable
IbcEventsEmitterABIis deprecated but still present. Verify if it is still needed or if it can be safely removed to avoid confusion.Consider removing the deprecated variable if it is no longer in use:
-// IbcEventsEmitterABI is the input ABI used to generate the binding from. -// Deprecated: Use IbcEventsEmitterMetaData.ABI instead. -var IbcEventsEmitterABI = IbcEventsEmitterMetaData.ABI
Line range hint
87-89: Redundant type assertion in error handlingIn the function
NewIbcEventsEmitter, the error handling could be simplified.Consider simplifying the error return line:
- if err != nil { - return nil, err - } + if err != nil { + return nil, fmt.Errorf("failed to bind IbcEventsEmitter: %w", err) + }This provides more context if the binding fails.
Line range hint
785-788: Potential performance improvement in event iterationThe
Next()method in event iterators can be optimized by reducing redundant checks.Consider restructuring the method to avoid checking
it.failandit.donemultiple times.Makefile (1)
69-69: Unnecessary use ofexit 1aftergo buildThe command
go build ./... || exit 1is redundant becausego buildwill exit with a non-zero status on failure.You can simplify the command:
- go build ./... || exit 1; \ + go build ./...; \bindings/go/protocounterparty/ProtoCounterparty.go (1)
Line range hint
23-24: Empty ABI in metadataThe
ABIfield inProtoCounterpartyMetaDatais empty. This might cause runtime errors when attempting to bind contract methods.Ensure that the ABI is correctly defined. If the contract does not have any methods, consider whether the binding is necessary.
bindings/go/iclientupdates/IClientUpdates.go (2)
Line range hint
47-50: Error handling in constructor functionsIn
NewIClientUpdates, errors frombindIClientUpdatesare returned directly. Consider adding context to the error message for better debugging.Modify the error return to include additional context:
- if err != nil { - return nil, err - } + if err != nil { + return nil, fmt.Errorf("failed to bind IClientUpdates: %w", err) + }
Line range hint
104-111: Type assertion may cause panicsIn the
LIGHTCLIENTTYPEfunction, the type assertion may panic if the contract does not return the expected type.Add error checking to ensure safe type conversion.
Apply this diff to handle the error gracefully:
out0, ok := out[0].(uint8) + if !ok { + return 0, fmt.Errorf("unexpected type for LIGHTCLIENTTYPE output") + } return out0, errbindings/go/revertingbytesmars/RevertingBytesMars.go (1)
Line range hint
1-894: Architecture aligns well with the PR objectives.The separation of the RevertingBytesMars contract into its own package:
- Improves modularity by avoiding naming conflicts
- Makes the codebase more maintainable
- Follows Go best practices for package organization
This change successfully addresses the original issue of build errors when multiple contracts were in the same package.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (12)
Makefile(1 hunks)bindings/go/iappstateverifier/IAppStateVerifier.go(1 hunks)bindings/go/ibceventsemitter/IbcEventsEmitter.go(1 hunks)bindings/go/ibcpacketsender/IbcPacketSender.go(1 hunks)bindings/go/iclientupdates/IClientUpdates.go(1 hunks)bindings/go/panickingmars/PanickingMars.go(1 hunks)bindings/go/protochannel/ProtoChannel.go(1 hunks)bindings/go/protocounterparty/ProtoCounterparty.go(1 hunks)bindings/go/revertingbytesmars/RevertingBytesMars.go(1 hunks)bindings/go/revertingemptymars/RevertingEmptyMars.go(1 hunks)bindings/go/revertingstringclosechannelmars/RevertingStringCloseChannelMars.go(1 hunks)bindings/go/revertingstringmars/RevertingStringMars.go(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- bindings/go/protochannel/ProtoChannel.go
🔇 Additional comments (15)
bindings/go/iappstateverifier/IAppStateVerifier.go (1)
4-4: Package name updated to iappstateverifier
Changing the package name to iappstateverifier aligns with the directory structure and enhances code organization.
bindings/go/panickingmars/PanickingMars.go (1)
4-4: Package name updated to panickingmars
Renaming the package to panickingmars reflects the specific functionality of the module and improves code clarity.
bindings/go/revertingemptymars/RevertingEmptyMars.go (1)
4-4: Package name updated to revertingemptymars
Updating the package name to revertingemptymars enhances alignment with the module's purpose and improves code organization.
bindings/go/revertingstringmars/RevertingStringMars.go (1)
4-4: Package name updated to revertingstringmars
Changing the package name to revertingstringmars accurately reflects the module's functionality and aids in maintaining a clear codebase.
bindings/go/revertingstringclosechannelmars/RevertingStringCloseChannelMars.go (1)
4-4: Package name updated to revertingstringclosechannelmars
Renaming the package to revertingstringclosechannelmars aligns with the module's specific functionality and improves code organization.
bindings/go/ibceventsemitter/IbcEventsEmitter.go (1)
4-4: Package name change may introduce import errors
The package name has been changed from ibcdispatcher to ibceventsemitter. Ensure that all references to this package in the codebase have been updated accordingly to prevent import errors.
Run the following script to identify any references to the old package name:
bindings/go/protocounterparty/ProtoCounterparty.go (1)
4-4: Package name change may introduce import errors
The package name has been changed from channel to protocounterparty. Ensure that all references to this package in the codebase have been updated accordingly to prevent import errors.
Run the following script to identify any references to the old package name:
bindings/go/ibcpacketsender/IbcPacketSender.go (2)
Line range hint 63-69: Check for correct contract method bindings
The method SendPacket has been defined. Ensure that the parameters and return types match the contract's actual implementation.
Double-check that the types [32]byte, []byte, and uint64 correctly correspond to the Solidity types in the contract.
4-4: Package name change requires codebase updates
The package name has been changed from ibcdispatcher to ibcpacketsender. Ensure that all references to this package have been updated to prevent import errors.
Run the following script to find references to the old package name:
bindings/go/iclientupdates/IClientUpdates.go (1)
4-4: Package name change may cause import issues
The package name has been changed from ilightclient to iclientupdates. Ensure that all references to ilightclient are updated.
Run the following script to find any outdated references:
bindings/go/revertingbytesmars/RevertingBytesMars.go (5)
4-4: LGTM: Package name follows the new convention.
The package name revertingbytesmars aligns with the PR objective of having separate packages for each contract, improving modularity and avoiding naming conflicts.
Line range hint 29-71: LGTM: Data structures are well-defined and properly mapped.
The Go structs (AckPacket, Height, IbcEndpoint, IbcPacket) are correctly generated from their Solidity counterparts with appropriate type mappings and maintain good Go naming conventions.
Line range hint 77-669: LGTM: Contract methods are well-structured and properly bound.
The contract methods are:
- Properly categorized (Caller, Transactor, Filterer)
- Well-documented with clear function signatures
- Implementing consistent error handling
Line range hint 671-894: LGTM: Event handling implementation is robust.
The OwnershipTransferred event handling:
- Follows standard Go patterns
- Implements proper iterator patterns with thread-safety
- Includes comprehensive error handling and resource cleanup
Line range hint 74-75: Verify ABI completeness and deprecation handling.
The code maintains backward compatibility by keeping the deprecated ABI variable while directing users to MetaData.ABI. Consider adding a deprecation timeline to help users plan their migration.
✅ Verification successful
Based on the results from the executed scripts, I can now provide a final response:
ABI deprecation handling is consistent with Go bindings best practices
The deprecation notice for RevertingBytesMarsABI follows the standard pattern used across all Go contract bindings in the codebase, directing users to use RevertingBytesMarsMetaData.ABI. The ABI is complete, containing all contract methods, events, and errors, including core functionality like greet, greetWithFee, and IBC-related methods.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify if there are any direct uses of the deprecated ABI variable
rg -l "RevertingBytesMarsABI" --type go
Length of output: 92
Script:
#!/bin/bash
# Check the context around the ABI usage to understand the deprecation notice and completeness
rg "RevertingBytesMarsABI" -A 5 -B 5 --type go
Length of output: 13833
Script:
#!/bin/bash
# Check MetaData.ABI definition and usage
rg "MetaData.ABI" --type go -A 2 -B 2
Length of output: 18218
Script:
#!/bin/bash
# Look for contract methods and events in the ABI
ast-grep --pattern 'var MetaData = &bind.MetaData{
$$$
}'
Length of output: 61
| mkdir -p ./bindings/go/$$pkg; \ | ||
| abigen --abi $$abi_file --pkg $$pkg --type $$type --out ./bindings/go/$$pkg/$$type.go; \ | ||
| done; \ | ||
| go build ./... || exit 1; \ |
There was a problem hiding this comment.
nit: you need the || exit 1. If go build fails, the make target will fail too.
There was a problem hiding this comment.
nit2: maybe add a message saying "running check sanity on bindings" or similar?
There was a problem hiding this comment.
(assuming you meant I don't need the exit 1 )
I think we actually do need this exit 1 to cause the root workflow to fail ; not sure if this is default behavior or maybe it's an os thing but the make command doesn't fail of the go build fails without the exit 1 - I tried this myself through replacing the go build ./... with go build ./. to cause it to fail due to not finding any files to build. Running the failing command without the exit command still causes the overall make command to pass.
Similar to the behavior we're seeing with abigen
There was a problem hiding this comment.
re second nit though I added messaging as you requested, thanks for the suggestion
There was a problem hiding this comment.
Sorry, I did mean "don't need" LOL
Make should propagate the errors thrown by shell commands executed by targets. Note that each line within a target is handled by a subshell. In your case you only have one command (single subshell) since you are concatenating commands like so cmd0; cmd1; cmd2; ... in which case you do have to exit
Here's a clear example
[nicolas@macbook foo]# cat Makefile
fail:
@echo hello
@go build ./.
@echo bye
shell:
@echo hello; \
go build ./.; \
echo bye;
exit:
@echo hello; \
go build ./. || exit 1; \
echo bye;
[nicolas@macbook foo]# make fail ; echo ">> $?"
hello
package .: no Go files in /private/tmp/foo
make: *** [fail] Error 1
>> 2
[nicolas@macbook foo]# make shell ; echo ">> $?"
hello
package .: no Go files in /private/tmp/foo
bye
>> 0
[nicolas@macbook foo]# make exit ; echo ">> $?"
hello
package .: no Go files in /private/tmp/foo
make: *** [exit] Error 1
>> 2
Things like for loops need to be within a single subshell (so you need the ; \) but other things could be in separate ones. Not a big deal though - it's ok as is.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
.github/workflows/foundry.yml (1)
44-44: Fix trailing whitespaceRemove the trailing spaces at the end of the line.
- RUN_FORK_TEST: true + RUN_FORK_TEST: true🧰 Tools
🪛 yamllint (1.35.1)
[error] 44-44: trailing spaces
(trailing-spaces)
test/Fork/Dispatcher.deploy.t.sol (3)
53-115: Consider extracting the setup logic to a separate methodThe setUp method has become quite large with the conditional logic. Consider extracting the setup implementation to a separate private method for better readability and maintainability.
function setUp() public override { if (!skipFork) { - ChainAddresses memory addresses = ChainAddresses(...); - // ... rest of the setup code ... + _performForkSetup(); } else { console2.log("skipping fork test since RUN_FORK_TEST was not set to true"); } } +function _performForkSetup() private { + ChainAddresses memory addresses = ChainAddresses( + IDispatcher(vm.envAddress("DispatcherProxy")), + IUniversalChannelHandler(vm.envAddress("UCProxy")), + ILightClient(vm.envAddress("OptimisticLightClient")), + vm.envAddress("OwnerAddress") + ); + // ... rest of the setup code ... +}
61-64: Consider improving comment formattingThe multi-line comment could be formatted better for readability.
- opLightClient = addresses.optimisticLightClient; // Need to set this so that when we call load_proof, it - // loads - // the proof to the right address + // Need to set this so that when we call load_proof, + // it loads the proof to the right address + opLightClient = addresses.optimisticLightClient;
70-73: Consider improving comment formattingSimilar to the previous comment, the multi-line comment could be formatted better.
- // For now, we need to change the portPrefix to that of the one which was used to generate the proof. We - // also - // have to set that for the connectionHop to light client mapping. + // For now, we need to change the portPrefix to that of the one + // which was used to generate the proof. We also have to set + // that for the connectionHop to light client mapping.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
.github/workflows/foundry.yml(1 hunks)test/Fork/Dispatcher.deploy.t.sol(1 hunks)
🧰 Additional context used
🪛 yamllint (1.35.1)
.github/workflows/foundry.yml
[error] 44-44: trailing spaces
(trailing-spaces)
🔇 Additional comments (3)
.github/workflows/foundry.yml (1)
44-44: LGTM: Environment variable addition for fork test control
The addition of RUN_FORK_TEST environment variable provides explicit control over fork test execution, which is properly utilized in the test implementation.
🧰 Tools
🪛 yamllint (1.35.1)
[error] 44-44: trailing spaces
(trailing-spaces)
test/Fork/Dispatcher.deploy.t.sol (2)
50-50: LGTM: Well-designed fork test control flag
The skipFork implementation with vm.envOr provides a good default (skip tests) while allowing override through environment variables.
119-119: LGTM: Proper test skip implementation
The use of vm.skip is the correct way to conditionally skip tests in Foundry, maintaining clean test output.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
Makefile (3)
40-44: Consider enhancing version checks with minimum version requirementsThe version checks are a good addition, but they could be more robust by validating minimum required versions of each tool.
Consider updating the checks like this:
version-check: - forge --version; \ - abigen --version; \ - go version; + forge --version | grep -q "forge" || (echo "forge not found" && exit 1); \ + abigen --version | grep -q "abigen" || (echo "abigen not found" && exit 1); \ + go version | grep -q "go version" || (echo "go not found" && exit 1);
72-72: Add more descriptive error messages for abigen failuresWhile the error handling is good, more descriptive error messages would help debugging.
Consider updating the error handling:
-abigen --abi $$abi_file --pkg $$pkg --type $$type --out ./bindings/go/$$pkg/$$type.go || exit 1; \ +abigen --abi $$abi_file --pkg $$pkg --type $$type --out ./bindings/go/$$pkg/$$type.go || { echo "Failed to generate bindings for $$type"; exit 1; }; \
74-74: Add descriptive message for bindings verificationGood addition of the build verification step, but it could be more informative.
Consider adding a descriptive message:
-go build ./... || exit 1; \ +echo "Verifying generated bindings..."; \ +go build ./... || { echo "Binding verification failed"; exit 1; }; \
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
Makefile(3 hunks)
🔇 Additional comments (3)
Makefile (3)
45-45: LGTM: Good addition of version check dependency
Adding version-check as a dependency ensures required tools are available before building.
70-70:
Package name derivation needs improvement for contract separation
The current package name derivation doesn't fully support the PR objective of generating separate packages per contract. The simple basename transformation might not create unique package names for contracts within the same .sol file.
Consider updating the package name derivation to include the contract name:
-pkg=$$(basename $$type .sol | tr "[:upper:]" "[:lower:]"); \
+pkg=$$(echo $$type | sed -E 's/([A-Z])/_\L\1/g' | sed 's/^_//'); \Line range hint 61-74: Verify the separation of contracts in generated bindings
The changes aim to generate separate packages per contract, but we should verify this works correctly.
✅ Verification successful
The output shows that the contracts are properly separated into different packages:
mars/Mars.gopanickingmars/PanickingMars.gorevertingbytesmars/RevertingBytesMars.gorevertingemptymars/RevertingEmptyMars.gorevertingstringclosechannelmars/RevertingStringCloseChannelMars.gorevertingstringmars/RevertingStringMars.go
Additionally, there were no duplicate package declarations found (the last command didn't produce any output, which means each .go file has a unique package).
Let me verify the package declarations to ensure they match their directory names:
Contract bindings are properly separated into individual packages
The verification confirms that:
- Each contract has its own directory under
bindings/go/ - Package names match their respective directory names
- All Mars-related contracts are correctly separated into individual packages (mars, panickingmars, revertingbytesmars, etc.)
- No duplicate package declarations were found
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if multiple contracts from the same .sol file are properly separated
# Check Mars.sol contracts separation
echo "Checking Mars contracts separation..."
find ./bindings/go -type f -name "*.go" | grep -i "mars" || echo "No Mars-related bindings found"
# Check for duplicate package declarations
echo "Checking for duplicate package declarations..."
find ./bindings/go -type f -name "*.go" -exec grep "^package" {} \; | sort | uniq -c | grep -v "^\s*1\s"
Length of output: 674
Script:
#!/bin/bash
# Check if package declarations match their directory names
for file in $(find ./bindings/go -type f -name "*.go"); do
echo "=== $file ==="
grep "^package" "$file"
done
Length of output: 8999
RnkSngh
force-pushed
the
raunak/fix-go-bindings
branch
from
0f8d8e3 to
ea44446
Compare
RnkSngh
force-pushed
the
raunak/fix-go-bindings
branch
from
ea44446 to
4540d19
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
.github/workflows/foundry.yml (1)
44-44: Remove trailing whitespace.There is a trailing space at the end of line 44 that should be removed.
Apply this diff to fix the formatting:
- RUN_FORK_TEST: true + RUN_FORK_TEST: true🧰 Tools
🪛 yamllint (1.35.1)
[error] 44-44: trailing spaces
(trailing-spaces)
Makefile (1)
69-71: Consider enhancing package name derivationThe current package name derivation might not handle all contract naming patterns correctly. Consider using a more robust approach for converting contract names to Go package names.
-pkg=$$(basename $$type .sol | tr "[:upper:]" "[:lower:]"); \ +pkg=$$(echo $$type | sed -E 's/([A-Z])/_\L\1/g' | sed 's/^_//' | tr '[:upper:]' '[:lower:]'); \This change would better handle CamelCase contract names by converting them to proper Go package naming conventions.
bindings/go/panickingmars/PanickingMars.go (1)
1-3: Consider enhancing error documentation.While the error handling is comprehensive, consider adding documentation comments for the custom error types (
ChannelNotFound,UnsupportedVersion,notIbcDispatcher) to improve maintainability.Add documentation comments above each error type in the ABI:
// Code generated - DO NOT EDIT. // This file is a generated binding and any manual changes will be lost. + // Error types: + // ChannelNotFound: Returned when the specified channel cannot be found + // UnsupportedVersion: Returned when the protocol version is not supported + // notIbcDispatcher: Returned when the caller is not the IBC dispatcher
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (14)
.github/workflows/foundry.yml(1 hunks)Makefile(3 hunks)bindings/go/iappstateverifier/IAppStateVerifier.go(1 hunks)bindings/go/ibceventsemitter/IbcEventsEmitter.go(1 hunks)bindings/go/ibcpacketsender/IbcPacketSender.go(1 hunks)bindings/go/iclientupdates/IClientUpdates.go(1 hunks)bindings/go/panickingmars/PanickingMars.go(1 hunks)bindings/go/protochannel/ProtoChannel.go(1 hunks)bindings/go/protocounterparty/ProtoCounterparty.go(1 hunks)bindings/go/revertingbytesmars/RevertingBytesMars.go(1 hunks)bindings/go/revertingemptymars/RevertingEmptyMars.go(1 hunks)bindings/go/revertingstringclosechannelmars/RevertingStringCloseChannelMars.go(1 hunks)bindings/go/revertingstringmars/RevertingStringMars.go(1 hunks)test/Fork/Dispatcher.deploy.t.sol(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- bindings/go/protochannel/ProtoChannel.go
- test/Fork/Dispatcher.deploy.t.sol
- bindings/go/iclientupdates/IClientUpdates.go
- bindings/go/protocounterparty/ProtoCounterparty.go
👮 Files not reviewed due to content moderation or server errors (3)
- bindings/go/revertingstringmars/RevertingStringMars.go
- bindings/go/revertingstringclosechannelmars/RevertingStringCloseChannelMars.go
- bindings/go/ibceventsemitter/IbcEventsEmitter.go
🧰 Additional context used
🪛 yamllint (1.35.1)
.github/workflows/foundry.yml
[error] 44-44: trailing spaces
(trailing-spaces)
🔇 Additional comments (11)
.github/workflows/foundry.yml (1)
44-44: LGTM! Verify the environment variable usage.
The addition of RUN_FORK_TEST: true aligns with the fork deployment testing requirements.
Let's verify how this environment variable is used in the test files:
✅ Verification successful
Environment variable RUN_FORK_TEST is correctly used in fork deployment tests
The environment variable is properly utilized in test/Fork/Dispatcher.deploy.t.sol to:
- Control fork test execution with appropriate default value (false)
- Provide clear logging when tests are skipped
- Follow environment variable naming conventions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check how RUN_FORK_TEST is used in the test files
# Search for RUN_FORK_TEST usage in test files
rg -t sol "RUN_FORK_TEST" test/
Length of output: 59
Script:
#!/bin/bash
# Search for RUN_FORK_TEST usage in all files under test directory
rg "RUN_FORK_TEST" test/
Length of output: 270
🧰 Tools
🪛 yamllint (1.35.1)
[error] 44-44: trailing spaces
(trailing-spaces)
Makefile (3)
42-44: LGTM: Version check enhancement
Good addition of version verification for forge with proper error handling.
59-60: LGTM: Tool version verification
Good addition of version checks for go and abigen with proper error handling.
73-75: LGTM: Build verification step
Good addition of build verification step with proper error handling and informative messaging.
bindings/go/ibcpacketsender/IbcPacketSender.go (1)
4-4: LGTM: Clean package structure
The generated binding follows good Go package naming conventions and properly isolates the IbcPacketSender contract into its own package.
bindings/go/iappstateverifier/IAppStateVerifier.go (2)
4-4: LGTM: Well-structured package
The generated binding follows good Go package naming conventions and properly isolates the IAppStateVerifier contract into its own package.
Line range hint 58-75: Verify binding generation across all contracts
The changes look good, but we should verify that bindings are generated correctly for all contracts, especially those with multiple contracts in the same Solidity file.
✅ Verification successful
Bindings are correctly generated for all contracts including those with multiple definitions
The verification shows that:
- All Solidity contracts, including files with multiple contract definitions (e.g., Mars.sol with 8 contracts, Dispatcher.sol with 24 contract references), have corresponding Go bindings.
- Each contract has its own dedicated package under
bindings/go/, following the one-package-per-contract structure. - The binding files maintain consistent naming patterns (e.g., Mars.go for Mars contract, RevertingStringMars.go for RevertingStringMars contract).
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify binding generation for contracts with multiple definitions
# Find all Solidity files with multiple contract definitions
echo "Checking Solidity files for multiple contract definitions..."
rg -l "^contract\s+\w+\s*{" | while read -r file; do
count=$(rg -c "^contract\s+\w+\s*{" "$file")
if [ "$count" -gt 1 ]; then
echo "File $file contains $count contract definitions"
# Show the contract definitions
rg "^contract\s+\w+\s*{" "$file"
fi
done
# Verify corresponding Go packages exist
echo "Checking generated Go packages..."
fd -t d . bindings/go/
Length of output: 1357
Script:
#!/bin/bash
# Let's fix the regex and try again to find contracts with multiple definitions
echo "Checking Solidity files for multiple contract definitions..."
rg -l "contract \w+" contracts/ | while read -r file; do
count=$(rg -c "contract \w+" "$file")
if [ "$count" -gt 1 ]; then
echo "File $file contains $count contract definitions"
echo "Contracts in $file:"
rg "contract \w+" "$file"
fi
done
# Let's also verify the binding files structure
echo -e "\nChecking Go binding files structure..."
for dir in bindings/go/*/; do
if [ -d "$dir" ]; then
echo -e "\nPackage: $dir"
ls -1 "$dir"
fi
done
Length of output: 22307
bindings/go/panickingmars/PanickingMars.go (1)
4-4: Package name change aligns with project objectives.
The package name change from mars to panickingmars effectively isolates this contract's bindings, preventing naming conflicts when multiple contracts are defined in the same Solidity file. This change directly addresses the PR's goal of separating contracts into their own modules.
bindings/go/revertingemptymars/RevertingEmptyMars.go (1)
4-4: Package organization maintains consistency.
The package renaming and structure follows the same pattern as panickingmars, maintaining consistency across the codebase.
bindings/go/revertingbytesmars/RevertingBytesMars.go (2)
4-4: Contract-specific error types properly isolated.
The package contains additional error types (OnRecvPacketRevert, OnTimeoutPacket) specific to this contract's functionality. This demonstrates the benefit of the package separation, as each contract can now maintain its own set of error types without conflicts.
Line range hint 1-1024: Verify package isolation and type uniqueness.
Let's verify that the package separation has effectively isolated contract-specific types and prevented naming conflicts.
✅ Verification successful
Based on the verification results, I can now provide a final response:
Duplicate struct definitions are intentional and required for Go bindings
The duplicate struct definitions (AckPacket, Height, IbcEndpoint, IbcPacket) across different packages are actually necessary and correct. Each package needs its own type definitions as they are generated bindings for different smart contracts. This is standard practice in Go bindings for Ethereum contracts to maintain proper type isolation between different contract interfaces.
Key findings:
- The old
marspackage still exists but appears to be a separate contract implementation - The struct definitions are properly scoped within their respective packages (revertingbytesmars, idispatcher, etc.)
- No actual type conflicts exist since each definition is package-scoped in Go
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that contract-specific types are properly isolated in their respective packages
# and that there are no naming conflicts across packages.
# Check for any remaining references to the old 'mars' package
echo "Checking for old package references..."
rg -l "package mars" ./bindings/go/
# Look for potential struct name conflicts across packages
echo "Checking for struct name conflicts..."
for struct in "AckPacket" "Height" "IbcEndpoint" "IbcPacket"; do
echo "Checking $struct..."
rg "type $struct struct" ./bindings/go/
done
# Verify that contract-specific errors are properly isolated
echo "Checking error type isolation..."
rg "type.*error.*struct" ./bindings/go/
Length of output: 66809
PR to make each contract wihtin each sol file have it's own module.
Previously, if we ran the
make bindings-gen-gocommand, it would produce go files which would not build for the mars contract, since it would declare all contracts declared in thecontracts/examples/Mars.sol(Mars, PanicingMars, etc) as part of one go module. This would produce errors if you tried to build the go bindings usinggo build ./...because it would result in doubly-declaring certain structs (e.g. AckPacket for Mars contracts). To allow our go bindings to be robust to having multiple contracts to be declared in the same sol files, we can declare each contract as part of it's own package.This should only impact users of the reverting/panicking mars (of which there are none), and
IbcDispatchergo bindingsSummary by CodeRabbit
New Features
Refactor
Bug Fixes