-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Create a macro which automates creation of benchmark test suites. #8104
Changes from 1 commit
24cf315
0209e4d
df14bba
dacbe67
47c795f
4b3be35
9577ee7
a6cf5d4
ebf64f0
e0444d8
cb6a33d
fd71312
7169e83
c382fb2
bd39a02
ebcf6d8
e0839c2
5e45e40
5c9f586
2730e07
4206191
9889fc9
10079b5
ffa7693
01964c6
3ef76f3
deb140f
c154611
f4cdd67
a350c64
6efac34
3e14cd2
681deaf
4e03f34
82f2a0d
7fcb460
db62d9f
5341906
1732671
f1859ee
f3d2f8f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
mod tests
- Loading branch information
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -993,14 +993,14 @@ macro_rules! impl_benchmark_test_suite { | |
| ($bench_module:tt, $new_test_ext:path, $test:path) => { | ||
| #[cfg(test)] | ||
| mod tests { | ||
| use super::*; | ||
| use super::{test_bench_by_name, $bench_module}; | ||
|
||
| use $crate::frame_support::assert_ok; | ||
|
|
||
| #[test] | ||
| fn test_benchmarks() { | ||
| $new_test_ext().execute_with(|| { | ||
| use $crate::Benchmarking; | ||
| for benchmark_name in $bench_module::<$test>::benchmarks(true) { | ||
| for benchmark_name in $bench_module ::<$test>::benchmarks(true) { | ||
| assert_ok!(test_bench_by_name::<$test>(benchmark_name)); | ||
|
||
| } | ||
| }); | ||
|
|
||
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.
Maybe we can use ident instead of
tt.Also here I guess we can't make it a
pathbecause later we do:$bench_module::<$test>::benchmarksand macro is failing to concatenate path somehow, isn't it?If this is the reason then we can consider moving to procedural macro also.
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.
That's precisely why we can't use
path. I'll try it withident. I'd prefer not to move to a procedural macro, if possible.Uh oh!
There was an error while loading. Please reload this page.
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.
why not moving to procedural ?
I actually prefer them, it is easier to extend and has less weird stuff like this
cc @shawntabrizi
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.
My main objection to procedural macros is that they're a heavy hammer: they take much longer to develop (at my level of experience) than macros-by-example. There is also some weirdness about requiring their own specially-configured crate. It doesn't feel worth it for a macro as small as
impl_benchmark_test_suitecurrently is.However, as I wrote in #8104 (comment), the only way I can see to get a single test case per benchmark is to merge the functionality into the
benchmarksmacro. Once I'm at that level of rewriting, I agree: it's worth the time to refactor the existing functionality into a procedural macro because doing so will be easier than substantially modifying a huge recursive macro by example such as currently exists.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.
My 2 cents is that once you get the initial scaffolding there, proc-marcos are well worth the extra time in the long run. For this use case, I'd admit that I would personally go with them, but can totally agree with that it is simpler to start with a simple
macro_rules.