Closed sanpii closed 3 years ago
For the first warning, I guess it would be safer to Box
the Expr
in the variant Return
to avoid a stack overflow in some cases.
For the functions with too many parameters, I'd just ignore them, as these are initializing structs with many fields anyway, so adding #[allow(clippy::too_many_arguments)]
should do.
For the last error (src/gen/generator.rs:65:70), just make the return type be a struct
instead of a tuple.
Also, it would be nice to run clippy
somewhere in the CI.
Thanks for looking into this!
For the first warning, I guess it would be safer to
Box
theExpr
in the variantReturn
to avoid a stack overflow in some cases.
Done, but destructuring Box
isn’t easy as a tuple.
For the functions with too many parameters, I'd just ignore them, as these are initializing structs with many fields anyway, so adding
#[allow(clippy::too_many_arguments)]
should do.
Ok, done.
For the last error (src/gen/generator.rs:65:70), just make the return type be a
struct
instead of a tuple.
I just created a type to limit API breaking. Why the gen
function is public? Public for crate is not enough? If you are ok, I can write another PR to restrict function visibility and change its return struct.
Also, it would be nice to run
clippy
somewhere in the CI.
Done.
Yep, the visibility can be crate
.
Ready to merge?
Yes, it’s ok for me.
I just created a type to limit API breaking. Why the
gen
function is public? Public for crate is not enough? If you are ok, I can write another PR to restrict function visibility and change its return struct.
Actually pub items is not really public (proc-macro lib forbids pub items other than proc macro). So I created a struct type for this return type.
Fixes #239 & #254
This PR is incomplete, there is still 4 warnings:
I don’t know how fix that.