-
Notifications
You must be signed in to change notification settings - Fork 77
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
Fix clippy and tests fail due to simple problems #415
Fix clippy and tests fail due to simple problems #415
Conversation
/// id: [u8; 4], | ||
/// #[tabled(format("{}.{}.{}.{}.{}", self.id[0], self.id[1], self.id[2], self.id[3], self.name)] | ||
/// id: u8, | ||
/// #[tabled(format("{}.{}", self.id, self.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.
We do not support formatting using complex expressions like self.id[0]
so I simplified this code a bit
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 actually one of my endless (not released patches) 😄
I did rewrite this support more then a few times.
I wonder what do you think in this regard.
Shall we support functions calls, array index etc?
#[tabled(format("{}.{}", some_function(self.id), self.name.one_more_field[100]))]
id: u8,
Why I did rewrote it is cause it's impossible to support in inline enums 😞
And having 2 different approaches in 2 different places seeeems like not the right approach.
#[derive(Tabled)]
enum Something {
#[tabled(inline)]
A {
#[tabled(format("{}", self.field1, func(0, 1, self)))] // <- impossible to complex expressions with self
field1: usize,
},
B {}
}
So anyway maybe you have some thoughts
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.
What do you mean by rewriting? What do we have now if this is not possible to implement for inline structs? Is this the same functionality I assumed for the test fix? If so, I'm sure that supporting more advanced formatting functionality is a good feature, but obviously, there are many complications that can affect the decision of whether it's worth implementing or not.
If you have patches that extend this functionality beyond the scope of the changed test, what should this test look like to test as much of #[tabled(format()]
as possible?
Hmmmm I did not realized it since today. If on
|
I think we need put some thinking to how to resolve it. |
tabled/src/settings/width/wrap.rs
Outdated
@@ -1431,7 +1441,7 @@ mod tests { | |||
"\u{1b}[37m(l\u{1b}[39m\u{1b}[37m\u{1b}[41marg\u{1b}[39m\u{1b}[49m\u{1b}[37mest \u{1b}[39m \n", | |||
"\u{1b}[37minteger \u{1b}[39m \n", | |||
"\u{1b}[37mless than \u{1b}[39m\n", | |||
"\u{1b}[37more equal \u{1b}[39m \n", | |||
"\u{1b}[37mor equal \u{1b}[39m \n", |
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 my fault, sorry folks
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 re-reviewed my previous fix typos
MR
to make sure I didn't make other mistakes and I've reverted these error
At the same time, I fix newly found typos
I hope you pardon my mistake and appreciate the MR
@@ -15,6 +15,7 @@ pub fn parse_field_attributes( | |||
} | |||
|
|||
pub struct FieldAttr { | |||
#[allow(dead_code)] |
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 choose to allow dead code
?
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'd like to hear from @zhiburt on this.
I see this field was added in ba048db. I know it was a long time ago, but do you remember why it exists but never read or it's fine if I remove it?
As for those #[allow(dead_code)]
that I left in the test code, I think the reason why they are there is more understandable - they are intended for fields that we never read in tests, but should be able to write to them
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.
As for those #[allow(dead_code)] that I left in the test code, I think the reason why they are there is more understandable - they are intended for fields that we never read in tests, but should be able to write to them
correct;
though these test could be cleaner I guess
if I remove it?
Will be all right.
As far as I think about it nowadays -unicode-width = "0.1"
+unicode-width = "=0.1.11" Once you do the failed tests must be fixed on its own. |
tabled_derive/src/parse/type_attr.rs
Outdated
@@ -14,6 +14,7 @@ pub fn parse_type_attributes( | |||
} | |||
|
|||
pub struct TypeAttr { | |||
#[allow(dead_code)] |
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.
shouldn't we also remove this dead code
?
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.
Damn, missed it, thanks
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 what reviews
are for
OK seems good to me 💯 Thanks @Alexdelia for review Have a good week; |
Closes #414
This PR fixes small issues that cause CI to fail due to failing tests and
cargo clippy
Testing
Local testing using
cargo test --workspace --no-fail-fast --all-features
andcargo clippy --all --all-targets --all-features