• Facade Generator
  • Gen & Set Facade in deploy sequence

When I tried a clean installation of TextDAO:4b1083d and then I got error below.

$ forge test                              
[⠢] Compiling...
[⠒] Compiling 110 files with 0.8.25
[⠢] Solc 0.8.25 finished in 753.71ms
Error: 
Compiler run failed:
(skip)
Error (8961): Function cannot be declared as view because this expression (potentially) modifies the state.
  --> lib/mc/devkit/utils/ForgeHelper.sol:27:16:
   |
27 |         return vm.envOr(envKey, address(0));
   |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Error (8961): Function cannot be declared as view because this expression (potentially) modifies the state.
  --> lib/mc/devkit/utils/ForgeHelper.sol:32:13:
   |
32 |         if (vm.envOr(envKey, address(0)).code.length != 0) return true;
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Error (8961): Function cannot be declared as view because this expression (potentially) modifies the state.
  --> lib/mc/devkit/utils/ForgeHelper.sol:59:16:
   |
59 |         return vm.getLabel(addr);
   |                ^^^^^^^^^^^^^^^^^
(skip)
Error (8961): Function cannot be declared as view because this expression (potentially) modifies the state.
  --> lib/mc/devkit/MCBase.sol:30:16:
   |
30 |         return vm.envOr(keyword, addr);
   |                ^^^^^^^^^^^^^^^^^^^^^^^

Just removing view and it will be fixed.

function propose() public predicates (link) is a bit non-intuitive.

I prefer function main() public executable or function run() public runnable for emphasising the principal function. (The "main/run" common naming can be much abstract and somewhat handy for multi-ops composability related matter.)

I've added code to check if a Dictionary is verifiable when deploying a Proxy and registering a Facade. This has inadvertently caused extra transactions to dictionary.implementation() during broadcast. A feature to detect if --broadcast is active is currently in development (foundry-rs/foundry#7377). Once implemented, I plan to adjust the code to only perform this check during a dry run. Until then, I will temporarily comment out this check.

Deployment.s.sol with certain complexity insists it is reached to "Stack too deep".

forge <subcommand> --via-ir evades that error but compilation is gonna be way too slow.

I guess JIT EVM can compress deployment code into LLVM and no stack problem would be shown tho. Let's discuss here.

ffi

• errors

• events

• external functions

• Facade Generator

  • Gen & Set Facade in deploy sequence

GitHub

• Templates
  • Create pull request template (.github/PULL_REQUEST_TEMPLATE.md)
  • Create issue templates (.github/ISSUE_TEMPLATE/**)
    • Bug report
    • Feature request
    • Support request
    • New release
• Settings
  • Set up branch protection rules
    • Require a pull request before merging
    • Require status checks to pass before merging
    • Require conversation resolution before merging
    • Require signed commits
    • Include administrators
  • Create organization project & link board
    • Todo, InProgress, InReview, Done
  • Set up issue and pull request labels
• GitHub Actions (Workflows)
  • Continuous Integration
    • Create .github/workflows/ci.yml
    • Set up jobs
      • format-check
        • setup forge fmt
      • tests
      • slither
      • coverage
  • Review Workflow Changes
    • Set up review CI for workflow definition files

Documentation

• README
  • Create README.md
  • Contents
    • Project overview
    • Installation instructions
    • Documentation guide
    • Contributing guide
    • License guide
• Changelog
  • Create CHANGELOG.md
  • Contents
    • Changelog overview
    • Example release log
• Contributing guidelines
  • Create CONTRIBUTING.md
  • Contents
    • Greeting
    • Reporting issues guide
    • Submitting pull requests guide
    • Coding style guide
      • #3
    • Release process guide
    • Versioning policy
    • Changelog rules guide
• Code of Conduct
  • Create CODE_OF_CONDUCT.md with Template
  • Fill the contract method
• Security policy
• License
  • Create LICENSE.md (blocking task: choose license)

Need to decide

• Choose appropriate license like MIT, Apache 2.0, GNU GPL
  • MIT
• Determine versioning strategy (Semantic Versioning, CalVer, etc.)
  • SemVer

Notifications and Reporting

• Set up status badges for the README
• Decide on the communication channel for the community (Telegram, Discord, Slack, Discourse, etc.)
  • Evaluate the features and limitations of each platform
  • Consider the preferences and familiarity of the team and community members
  • Choose the most suitable platform based on the project's needs
• Set up notifications and report generation for the selected communication channel
  • Add notification job
  • Configure various report outputs (coverage, analysis results, etc.)

UsePredicate and predicates modifier are intuitively hardher to get how to use from the current test.

• By defining StorageReader as a library, it becomes possible to handle storage returns (StorageReader should only be used during testing, so this shouldn't be a problem).

• In the test contract, register the dictionary of the deployed mc, and set it to make delegatecalls to the proxy and save the state in the test contract. This way, the StorageReader library can be used to read the state.

  • However, when using this method, developers must specify delegatecall every time they access mc, which reduces readability. Therefore, an appropriate wrapper contract needs to be prepared (TODO).
  • Moreover, when writing tests that handle multiple mcs, only one dictionary can be registered in the test contract (requiring clever solutions like integrating dictionaries).

Methods

• mc.set() overloads

Validation

• A function to check if the appropriate ERC-7201 slots are specified

Deployment

• Enhance UCS Contract with CREATE2 Compatibility
• Facade Generator
  • #18

Testing

• State Fuzzing
• Mock Contracts
• Storage Reader
  • #28

Debugger

TODOs:

• README
  • #1
• LICENSE
• CONTRIBUTING
• CODE_OF_CONDUCT

When I tried a clean installation of TextDAO:4b1083d and then I got error below.

this.setImplementation solved this compilation error.

P.S. ofc if we have CI flow and better specs, those errors would be detected beforehand tho.

$ forge test
[⠆] Compiling...
[⠒] Compiling 110 files with 0.8.25
[⠑] Solc 0.8.25 finished in 221.25ms
Error: 
Compiler run failed:
Error (7576): Undeclared identifier.
  --> lib/mc/devkit/test/MockDictionary.sol:15:13:
   |
15 |             setImplementation(functionInfos[i].selector, functionInfos[i].implementation);
   |             ^^^^^^^^^^^^^^^^^

As per current commit (257d4f5), Solidity v0.8.24 is the supported version for the meta contract framework.

I'm building slot extractor here and it requires AST of Schema.sol.

Status Quo

• With some version of Foundry and Solidity, we can get out/Schema.sol/Schema.json with has valid ast field.
• Latest Foundry and Solidity v0.8.24 didn't give us that.
• solc-typed-ast is only supporting until Solidity v0.8.17

Preferred Requirement

• mc to support Solidity v0.8.17