Navigation Menu

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

Add binding for git_message_trailers #749

Merged
merged 20 commits into from Oct 18, 2021
Merged

Add binding for git_message_trailers #749

merged 20 commits into from Oct 18, 2021

Conversation

LemmingAvalanche
Copy link
Contributor

No description provided.

@LemmingAvalanche
Copy link
Contributor Author

I don’t know how to fix the current error from the CI.

The output on my machine:

$ if [[ "stable" != "nightly" ]]; then cargo run --manifest-path systest/Cargo.toml; fi
…
  running: "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m64" "-I" "<path-to-repo>/target/debug/build/libgit2-sys-b48a2ccdd54f1249/out/include" "-Wall" "-Wextra" "-Wall" "-Wextra" "-Werror" "-Wno-unused-parameter" "-Wno-type-limits" "-Wno-address-of-packed-member" "-Wno-unknown-warning-option" "-Wno-deprecated-declarations" "-o" "<path-to-repo>/target/debug/build/systest-ae23871569b4b2ee/out/all.o" "-c" "<path-to-repo>/target/debug/build/systest-ae23871569b4b2ee/out/all.c"
  cargo:warning=<path-to-repo>/target/debug/build/systest-ae23871569b4b2ee/out/all.c: In function ‘__test_field_type_git_message_trailer_array_trailers’:
  cargo:warning=<path-to-repo>/target/debug/build/systest-ae23871569b4b2ee/out/all.c:18438:28: error: return from incompatible pointer type [-Werror=incompatible-pointer-types]
  cargo:warning=                     return &b->trailers;
  cargo:warning=                            ^~~~~~~~~~~~
  cargo:warning=<path-to-repo>/target/debug/build/systest-ae23871569b4b2ee/out/all.c: At top level:
  cargo:warning=cc1: error: unrecognized command line option ‘-Wno-unknown-warning-option’ [-Werror]
  cargo:warning=cc1: error: unrecognized command line option ‘-Wno-address-of-packed-member’ [-Werror]
  cargo:warning=cc1: all warnings being treated as errors
  exit code: 1

  --- stderr
  rust version: 1.47.0


  error occurred: Command "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m64" "-I" "<path-to-repo>/target/debug/build/libgit2-sys-b48a2ccdd54f1249/out/include" "-Wall" "-Wextra" "-Wall" "-Wextra" "-Werror" "-Wno-unused-parameter" "-Wno-type-limits" "-Wno-address-of-packed-member" "-Wno-unknown-warning-option" "-Wno-deprecated-declarations" "-o" "<path-to-repo>/target/debug/build/systest-ae23871569b4b2ee/out/all.o" "-c" "<path-to-repo>/target/debug/build/systest-ae23871569b4b2ee/out/all.c" with args "cc" did not execute successfully (status code exit code: 1).

The C function at line 18438 in that file:

const git_message_trailer** __test_field_type_git_message_trailer_array_trailers(git_message_trailer_array* b) {
    return &b->trailers;
}

The error output from the CI is better than the one on my machine:

error: returning ‘git_message_trailer **’ {aka ‘struct <anonymous> **’} from a function with incompatible return type ‘const git_message_trailer **’ {aka ‘const struct <anonymous> **’} [-Werror=incompatible-pointer-types]

How can I provide a better type in src/libgit2-sys/lib.rs?

@alexcrichton
Copy link
Member

That looks like a difference of *const and *mut in Rust I think?

Fix error from `cargo run --manifest-path systest/Cargo.toml;`.

You can’t just mix and match `*mut` and `*const` like that.
@LemmingAvalanche
Copy link
Contributor Author

Oh wow. Yep, that was it. Thanks!

Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

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

Thanks again for this! I left some comments but otherwise this is looking pretty good!

src/message.rs Outdated
/// Collection of trailer key–value pairs.
///
/// Use `iter()` to get access to the values.
pub struct MessageTrailers<'pair> {
Copy link
Member

Choose a reason for hiding this comment

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

I believe that this is a uniquely owned value, so I don't think that a 'pair lifetime parameter here is necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See rev. f6fd4b7

src/message.rs Outdated
}
}

impl<'pair> Binding for MessageTrailers<'pair> {
Copy link
Member

Choose a reason for hiding this comment

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

I think this may not actually be necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See rev. b0015cc

src/message.rs Outdated
/// A borrowed iterator.
pub struct MessageTrailersIterator<'pair> {
trailers: &'pair MessageTrailers<'pair>,
counter: usize,
Copy link
Member

Choose a reason for hiding this comment

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

One thing I might recommend is to change this to Range<usize> so that way next() is easy to implement.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Never heard of, but I like it!

See rev. e94008a

src/message.rs Outdated
}
}

struct Trailer<'pair> {
Copy link
Member

Choose a reason for hiding this comment

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

This is a one-off struct just for the method below so I think it's fine to remove this and just inline the method into the iterator implementation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See rev. 55ea909

}
}
}
}
Copy link
Member

Choose a reason for hiding this comment

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

Could you add implementations for size_hint and ExactSizeIterator here as well? (which would also necessitate DoubleEndedIterator, and the implementations should be relatively easy if the counter field is changed to a Range)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I implemented len() for ExactSizeIterator. The doc says that size_hint() can be derived from it. I couldn’t implement size_hint() myself.

The doc says that len() has a default implementation, but I guess just returning the value directly wouldn’t be less efficient than whatever the default impl. is.

See rev. e7b0306

Suggested-by: Alex Crichton <alex@alexcrichton.com>
See: #749 (comment)
Suggested-by: Alex Crichton <alex@alexcrichton.com>
See: #749 (comment)
I love it.

Suggested-by: Alex Crichton <alex@alexcrichton.com>
See: #749 (comment)
Suggested-by: Alex Crichton <alex@alexcrichton.com>
See: #749 (comment)
Also change `to_str_tuple(…)` in order to share more code between two of
the iterators.

Suggested-by: Alex Crichton <alex@alexcrichton.com>
See: #749 (comment)
@LemmingAvalanche
Copy link
Contributor Author

What are your preferences with regards to rebase?

Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

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

This'll get rebased when merged so no need to worry about manual rebasing!

src/message.rs Outdated
_marker: marker::PhantomData<c_char>,
}

impl<'pair> MessageTrailers {
Copy link
Member

Choose a reason for hiding this comment

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

Since the type doesn't have a lifetime parameter any more this shoudl move down to the iter method itself, but even on the iter method it can be elided and it can return MessageTrailersIterator<'_>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See rev e450945

src/message.rs Outdated
/// Use `iter()` to get access to the values.
pub struct MessageTrailers {
raw: raw::git_message_trailer_array,
_marker: marker::PhantomData<c_char>,
Copy link
Member

Choose a reason for hiding this comment

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

This I don't believe is necessary any longer.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See rev a0bd026

}

impl<'pair> Iterator for MessageTrailersIterator<'pair> {
type Item = (&'pair str, &'pair str);
Copy link
Member

Choose a reason for hiding this comment

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

Could this perhaps be an iterator of &[u8] instead of &str to allow for non-utf8 messages?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I’ve gone back and forth on the UTF-8 issue. I think I ended up trying to do what message_prettify(…) does, and that function seems to assume that it gets a UTF-8 string back. It seems though that it can send in a non-UTF-8 string since it passes in a IntoCString (as does message_trailers(…)), in which case it would error out when it gets non-UTF-8 strings back (if I’ve read the code correctly).

Supporting &[u8] seems good, but what about both types? It seems inconvenient to send in a UTF-8 string to C, get back &[u8] values that you know are UTF-8 and then having to convert or assert that they are also valid as &str.

Copy link
Member

Choose a reason for hiding this comment

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

Eh I could also go either way on this. I don't think the bindings are super principled so far, some of the time it tries to give you bytes and other times it gives you strings. I don't really mind either way on this, we can always add a separate iterator in the future specifically for bytes if strings becomes a problem.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See rev 70b7ebd

src/message.rs Outdated

impl ExactSizeIterator for MessageTrailersIterator<'_> {
fn len(&self) -> usize {
self.range.end
Copy link
Member

Choose a reason for hiding this comment

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

This'll want to be self.range.len() since the length changes over time.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See rev 34fa7b5

self.range
.next()
.map(|index| to_str_tuple(&self.trailers, index, marker::PhantomData))
}
Copy link
Member

Choose a reason for hiding this comment

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

Could you add size_hint here too?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah okay I think I understand now. I confused myself thought that size_hint() was part of ExactSizeIterator.

See rev 16321f3

src/message.rs Outdated
}
}

#[inline(always)]
Copy link
Member

Choose a reason for hiding this comment

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

This annotation isn't necessary

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See rev 023fb92

@LemmingAvalanche
Copy link
Contributor Author

Something unrelated: cargo fmt wants to do this change:

diff --git a/src/util.rs b/src/util.rs
index 1c6001ddbf60..a31e63bce2c3 100644
--- a/src/util.rs
+++ b/src/util.rs
@@ -204,7 +204,7 @@ pub fn c_cmp_to_ordering(cmp: c_int) -> Ordering {
 pub fn path_to_repo_path(path: &Path) -> Result<CString, Error> {
     macro_rules! err {
         ($msg:literal, $path:expr) => {
-            return Err(Error::from_str(&format!($msg, $path.display())))
+            return Err(Error::from_str(&format!($msg, $path.display())));
         };
     }
     match path.components().next() {

But that causes one of the CI checks to fail (corrected in f35b68f and cd4c2db).

This is also what cargo fmt -- --check in the CI proposes. At least on my machine.

Are you supposed to give an option/argument to cargo fmt?

@alexcrichton
Copy link
Member

This all looks great to me, thanks! No worries about the extra change, we just bow to whatever the rustfmt gods say we should do.

@alexcrichton alexcrichton merged commit 4461b17 into rust-lang:master Oct 18, 2021
@LemmingAvalanche LemmingAvalanche deleted the message-trailers branch October 18, 2021 16:10
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.

None yet

2 participants