Skip to content
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

Refactoring modules into parser:: and types:: + minor cleanups #80

Closed
wants to merge 19 commits into from
Closed

Refactoring modules into parser:: and types:: + minor cleanups #80

wants to merge 19 commits into from

Conversation

duesee
Copy link
Contributor

@duesee duesee commented Mar 25, 2020

No description provided.

@duesee
Copy link
Contributor Author

duesee commented Mar 25, 2020

I also added an example, so that someone who is unsure wheather to use this library or not can see what it does.

is_ is useful to distinguish between predicates and parsers. This prefix
is also used in nom.
@duesee duesee changed the title Refactoring modules into parser:: and types:: Refactoring modules into parser:: and types:: + minor cleanups Mar 25, 2020
Copy link
Owner

@djc djc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, a bunch of feedback. Note that in general I like this work, and pretty much all of the feedback about how you're presenting it for review. On that front, I'm intentionally on the strict side here so that in the future reviewing will be quicker and we don't have to go round for round. I hope that's okay. Also if you want to push back on any feedback I give that's fine, let's discuss if you disagree!

// QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> / "\" quoted-specials
// quoted-specials = DQUOTE / "\"
// TEXT-CHAR = <any CHAR except CR and LF>
/// Returns an escaped string if necessary for use as a "quoted" string per
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this (changing comments to docstring) seems unrelated to the goal of the commit (which seems to be reordering code). I also don't see much point in it, since quoted_string() is not exported.

Copy link
Contributor Author

@duesee duesee Mar 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two points: 1) it is still semantically a docstring (even though it is private and might never be exported in the future) 2) CLion -- and this is the real reason I changed it -- is now able to collapse it ;-)

@@ -63,6 +59,10 @@ fn quoted_string(s: &str) -> Result<Cow<str>, &'static str> {
}
}

#[cfg(test)]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

extern crate statements should be near the top IMO. Moving this here doesn't make sense to me.

@@ -14,6 +14,22 @@ struct BodyFields<'a> {
pub octets: u32,
}

struct BodyExt1Part<'a> {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This moves the type definitions further away from their single usage sites. That makes this code harder to modify. To me, the parsers that result in these types should probably be treated akin to an impl block, which I always keep immediately below type definitions.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, now that I've seen the follow-up commit that moves the type definitions, I actually understand the goal here. As such, I would prefer to have these two commits squashed together, because this one doesn't make sense on its own (otherwise, please explain any deferred purpose in the commit message).

@@ -1,5 +1,4 @@
use nom::{self, IResult};

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like to keep std imports and imports from other crates separate. (Usually these days I put std imports first, then a blank line, then all imports from other crates, then another blank line, then imports from this crate.)

use crate::body::*;
use crate::body_structure::*;

use crate::{
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above.

@@ -118,7 +117,7 @@ fn entry_name(i: &[u8]) -> IResult<&[u8], &[u8]> {
}

fn slice_to_str(i: &[u8]) -> &str {
str::from_utf8(i).unwrap()
std::str::from_utf8(i).unwrap()
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also appears to belong in an earlier commit.

@@ -13,7 +13,7 @@ use tokio_util::codec::Decoder;

use crate::proto::{ImapCodec, ImapTransport, ResponseData};
use imap_proto::builders::command::Command;
use imap_proto::{Request, RequestId, State};
use imap_proto::types::{Request, RequestId, State};
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be fixed in the commit that introduced it.

@@ -23,6 +23,46 @@ use crate::{
pub mod body;
pub mod body_structure;

pub fn parse_response(msg: &[u8]) -> ParseResult {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want this hoisted up top on its own, we should reorder the entire module at once to flow from high-level to low-level.

@@ -49,7 +49,7 @@ pub fn quoted_data(i: &[u8]) -> IResult<&[u8], &[u8]> {
}

// quoted-specials = DQUOTE / "\"
pub fn quoted_specials(c: u8) -> bool {
pub fn is_quoted_specials(c: u8) -> bool {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. 👍

data: take!(len) >> // FIXME: 0x00 is not allowed
(data)
));
/// literal = "{" number "}" CRLF *CHAR8
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to split this into two commits: one commit that converts literal to function-style, and one commit that makes it more strict. Otherwise, it makes reviewing stuff much harder.

@duesee
Copy link
Contributor Author

duesee commented Mar 25, 2020

Thank you for the feedback! Makes all sense :-) There is only one problem... I have no idea how to split commits in a PR. Should I close this one first? I will try tomorrow evening.

@djc
Copy link
Owner

djc commented Mar 26, 2020

I usually use git rebase -i to do an interactive rebase. If you set that to edit the offending commit, you can then git reset HEAD^ to reset the branch pointer to the previous commit while keeping your changes, so you can make new commits with git commit -p or similar.

@duesee
Copy link
Contributor Author

duesee commented Mar 27, 2020

Okay, I think I learned how to squash, rearrange and split commits :-) See #81. I added 3 more commits here which you can review. Otherwise the new branch is identical to this one. Just so you don't have to review anything twice.

@duesee duesee closed this Mar 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants