-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add Optimism bindings in N-API #664
Conversation
|
use itertools::izip; | ||
|
||
/// Trait for a function that decodes console log inputs. | ||
pub trait DecodeConsoleLogInputsFn: Fn(Vec<Bytes>) -> Vec<String> + Send + Sync {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We now deal with Rust Fn
s instead of the ThreadSafeFunction
and JsFunction
in this file. This creates a clear demarcation between marshalled types and internal types.
scenarios = ["rand"] | ||
|
||
[profile.release] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cargo
was reporting that this setting was ignored. Only the workspace Cargo.toml
's profile are respected.
@@ -10,7 +10,6 @@ on: | |||
workflow_dispatch: | |||
|
|||
env: | |||
RUSTFLAGS: -Dwarnings |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was overriding the .cargo/config.toml
file's rustflags.
This change should not have any adverse side-effects, as we also manually pass this argument to cargo clippy
which should fail if there are any warnings.
For reference:
cargo clippy --workspace --all-targets --all-features -- -D warnings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanatory comment! I'm wondering if removing it has effect on the check-edr
and test-edr-rs
? E.g. if there are some unused imports with some feature combination, would the CI not fail now? It's not a merge blocker for me if it doesn't, just want to make sure we consider it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Given that we use cargo hack
in check-edr
, we would lose some functionality - I think. I've re-added the environment variables for that specific command here.
Clippy catches all warnings that cargo check|build|test
would catch, as it is a superset of the check command - under the hood. Since we run cargo clippy
with --all-targets
, the test target is also run.
This means that it's possible for the test-edr-rs
step to succeed with warnings, but the step running cargo clippy
would fail the CI.
To validate this, I just added two simple functions (dead code) to lib.rs
:
fn foo() {
println!("foo");
}
#[cfg(test)]
fn bar() {
prinltn!("bar");
}
Running cargo check --all-targets
gives the following warnings:
warning: function `foo` is never used
--> crates/edr_eth/src/lib.rs:62:4
|
62 | fn foo() {
| ^^^
|
= note: `#[warn(dead_code)]` on by default
warning: `edr_eth` (lib) generated 1 warning
warning: function `bar` is never used
--> crates/edr_eth/src/lib.rs:67:4
|
67 | fn bar() {
| ^^^
warning: `edr_eth` (lib test) generated 2 warnings (1 duplicate)
These become errors when running cargo clippy --all-targets -- -D warnings
(failing one at a time):
error: function `foo` is never used
--> crates/edr_eth/src/lib.rs:62:4
|
62 | fn foo() {
| ^^^
|
= note: `-D dead-code` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(dead_code)]`
error: could not compile `edr_eth` (lib) due to 1 previous error
error: function `bar` is never used
--> crates/edr_eth/src/lib.rs:63:4
|
63 | fn bar() {
| ^^^
|
= note: `-D dead-code` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(dead_code)]`
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## feat/multichain #664 +/- ##
==================================================
Coverage ? 63.05%
==================================================
Files ? 215
Lines ? 23689
Branches ? 23689
==================================================
Hits ? 14938
Misses ? 7837
Partials ? 914 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! I left some questions + there seems to be a lot of CI errors
@@ -10,7 +10,6 @@ on: | |||
workflow_dispatch: | |||
|
|||
env: | |||
RUSTFLAGS: -Dwarnings |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanatory comment! I'm wondering if removing it has effect on the check-edr
and test-edr-rs
? E.g. if there are some unused imports with some feature combination, would the CI not fail now? It's not a merge blocker for me if it doesn't, just want to make sure we consider it.
.cargo/config.toml
Outdated
|
||
# To be able to run unit tests on Linux, support compilation to 'x86_64-unknown-linux-gnu'. | ||
[target.'cfg(target_os = "linux")'] | ||
rustflags = ["-C", "link-args=-Wl,--warn-unresolved-symbols"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have any unit tests that need this now? If not, I'd rather not add it tbh, because if I understand correctly, this will turn linker errors into warnings for all targets which means we might have build errors and not notice it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, it sounds like napi_build
always does this under the hood because it's linked dynamically.
napi-rs/napi-rs#1005 (comment)
napi-rs/napi-rs#1782 (comment)
I agree that we should avoid setting this for the workspace. I have removed both instances for now, as there are no tests using edr_napi
crates/edr_napi/.cargo/config.toml
Outdated
|
||
# To be able to run unit tests on Linux, support compilation to 'x86_64-unknown-linux-gnu'. | ||
[target.'cfg(target_os = "linux")'] | ||
rustflags = ["-C", "link-args=-Wl,--warn-unresolved-symbols"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
l1ProviderFactory, | ||
MineOrdering, | ||
SubscriptionEvent, | ||
// HACK: There is no way to exclude tsc type checking for a file from the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no way to exclude files from tsc
via the command-line (microsoft/TypeScript#46005)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into my comments, LGTM!
This PR exposes Optimism through the N-API bindings, toggled using the
optimism
feature flag. It's a modified version of #659.It also incorporates a fix for linker failure on Linux when building the test target and creates a clear split between internal (Rust) and external (N-API) types. The internal types live in in
edr_napi_core
.I noticed that we need to be aware of mixed usage of
pnpm build
andpnpm build:optimism
, as it will likely result in the Optimism bindings being committed by accident. This mistake will be caught by CI.