-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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(metrics): Metrics
derive macro
#592
Conversation
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.
I like this a lot.
some nits.
also I'd be great to have some simple tests: ref https://github.com/metrics-rs/metrics/blob/main/metrics-macros/src/tests.rs
re crate name, maybe we'll have additional metrics stuff so I'd suggest we name this metrics-macros
?
Codecov Report
@@ Coverage Diff @@
## main #592 +/- ##
==========================================
+ Coverage 72.00% 72.25% +0.24%
==========================================
Files 251 255 +4
Lines 25478 25737 +259
==========================================
+ Hits 18345 18595 +250
- Misses 7133 7142 +9
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
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 from me. Nice work. Thinking we should extract some of these general token parsing utils to a separate crate for use inside of Foundry, ethers and here.
/// Describe all exposed metrics. Internally calls `describe_*` macros from | ||
/// the metrics crate according to the metric type. | ||
/// Ref: https://docs.rs/metrics/0.20.1/metrics/index.html#macros |
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.
@mattsse iirc this does not work and requires #[doc = ...]
?
/// } | ||
/// } | ||
/// ``` | ||
#[proc_macro_derive(Metrics, attributes(metrics, metric))] |
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.
great docs here
@@ -0,0 +1,180 @@ | |||
use std::{collections::HashMap, sync::Mutex}; |
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.
great work in these tests. really clear.
@@ -0,0 +1,5 @@ | |||
#[test] | |||
fn compile_test() { | |||
let t = trybuild::TestCases::new(); |
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.
also really neat - TIL
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.
First, if a test case is being run as compile_fail but a corresponding *.stderr file does not exist, the test runner will save the actual compiler output with the right filename into a directory called wip within the directory containing Cargo.toml. So you can update these files by deleting them, running cargo test, and moving all the files from wip into your testcase directory.
Alternatively, run cargo test with the environment variable TRYBUILD=overwrite to skip the wip directory and write all compiler output directly in place. You'll want to check git diff afterward to be sure the compiler's output is what you had in mind.
https://github.com/dtolnay/trybuild#workflow - really sick work @dtolnay, thanks for the crate
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.
i've spent a couple of hours battling compiletest-rs
and rustc lib linkage before finding this gem. indeed, great work, really easy to use
bin/reth/src/node/mod.rs
Outdated
@@ -26,9 +26,8 @@ use reth_network::{ | |||
use reth_primitives::{Account, Header, H256}; | |||
use reth_provider::{db_provider::ProviderImpl, BlockProvider, HeaderProvider}; | |||
use reth_stages::{ | |||
stage_metrics::HeaderMetrics, |
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.
a question about the naming convention for the metrics modules, what do you think about following the structure
<crate>::metrics;
instead of, like in this case,
<crate>::<crate>_metrics;
I think it would be slightly nicer and less verbose
awesome work! Just a little suggestion about the naming convention of the metrics modules inside each crate |
@entropidelic sgtm, |
quick heads up, metrics scopes of the form |
Should we rename everything to use underscores and validate that in the macro? |
@prestwich you're right, thanks for the heads up |
This PR introduces
Metrics
derive macro to reduce code duplication for declaring, registering and deriving metrics.Addresses #584 (comment)