[WIP] integrating zksync_error

[sayon]

What 💻

• Integration or a declarative error definition library

Why ✋

• Better UX through uniform error handling and reporting
• Documentation -- online (reactive) and offline

Evidence 📷

$ touch anvil-zksync.log && chmod 000 anvil-zksync.log && cargo run 
Error: [anvil-env-1] Unable to access log file: anvil-zksync.log
ErrorDocumentation {
    description: "Anvil was unable to open the log file for writing.",
    short_description: "Unable to access log file.",
    likely_causes: [
        LikelyCause {
            cause: "Not enough space.",
            fixes: [
                "Check if you have enough free space in your storage to create or open a log file",
            ],
            report: "",
            owner: None,
            references: [],
        },
        LikelyCause {
            cause: "Insufficient permissions.",
            fixes: [
                "Check if you have permissions to write to the log file.",
            ],
            report: "",
            owner: None,
            references: [],
        },
    ],
}
Error: Anvil(AnvilEnvironment(LogFileAccessError { log_filename: "anvil-zksync.log", wrapped_error: "Permission denied (os error 13)" }))

Regenerate zksync_error:

zksync-error-codegen-cli --root-definitions https://raw.githubusercontent.com/sayon/error-codegen-poc/refs/heads/main/zksync-root.json --additional-definitions etc/resources/anvil.json --backend rust --verbose --output=crates/zksync_error/

[dutterbutter]

Question, do we need to specify all the varying components in this integration with anvil-zksync? For instance, FoundryUpstream related errors would not be relevant from anvil-zksync, the same with compiler related components as anvil-zksync does not compile anything?

[sayon]

Ah, there seems to be a confusion here!

When we generate the crate zksync_error we use

• the root definition file, currently here: https://github.com/sayon/error-codegen-poc/blob/main/zksync-root.json
• the root may link to other files, and we may provide additional files explicitly, such as the local resources/anvil.json file.

So, anvil-zksync developer should only edit this file: https://github.com/matter-labs/anvil-zksync/blob/2bb8a99b78815f9f65530ae8601d6fc800f70eaa/etc/resources/anvil.json
It does not contain any definitions related to other projects.

This file (zksync_error/resources/model.json) is the combined model, dumped, containing all consumed json files. It should not be edited as it serves two purposes:

1. Debugging -- you will see what is the result of fetching JSON files and merging them together, prior to zksync_error code generation.
2. Documentation in runtime is taken from there (once per executable launch).

[popzxc]

Maybe insert something like this in the beginning? (Hope it won't be hard to strip comments in json if parser you use doesn't do that already)

/// Autogenerated by <binary-name>.
/// Do not edit manually!
/// Keep this file in the source control.

[itegulov]

Last time I checked out your repo there was a way to generate code from build.rs, any reason not to use that here? From what I remember you were working on a way to reference dependencies via cargo thus not needing to use CLI at all. Admittedly I am a bit out of loop so sorry if this has been went through already 😅

[sayon]

We can still do it using build.rs! We can do it here too, it's just optional and a bit dirty (build.rs in one crate is used to generate code for another crate, as build.rs can not live in the workspace root...)

We can also fetch parts of error hierarchy from cargo packages rather then by direct links. However we need a language agnostic approach (or at least something that combines well with both JS and Rust ecosystems), and cargo is not :(

[itegulov]

Hmm, I was kind of expecting crate's build.rs to just write files to ./gen and then we would include!(../gen/mod.rs) them from src/lib.rs. This is the most common approach I have seen in Rust ecosystem. Is there a reason this doesn't work for us?

We can also fetch parts of error hierarchy from cargo packages rather then by direct links. However we need a language agnostic approach (or at least something that combines well with both JS and Rust ecosystems), and cargo is not :(

Makes sense

[popzxc]

I was the one who voted against build.rs approach -- while certainly neat, it makes it super hard to see the actual code being produced, which may kill the adoption (as not everyone is a rust expert). We can change the approach later, but for now I think that we should opt for ease of use.

[itegulov]

Well, we don't have to obfuscate the code generated from build.rs - I would pipe it through rustfmt and organize into proper files just like in this PR. And I would still keep them in the source control to see what actually gets changed in each PR that modifies error files. IMO typical user would observe only one difference between the two approaches: rust-analyzer/IDE support for include!() can be wonky at times.

Regardless, no strong opinion here from my side especially since I am super late to the party 😅