From: "Erik Schilling" <erik.schilling@linaro.org>
To: "Kent Gibson" <warthog618@gmail.com>
Cc: <linux-gpio@vger.kernel.org>, <brgl@bgdev.pl>, <viresh.kumar@linaro.org>
Subject: Re: [libgpiod][PATCH] bindings: rust: fix clippy lint warnings
Date: Mon, 19 Jun 2023 10:13:52 +0200 [thread overview]
Message-ID: <CTGH61DGZBIQ.RVXF4UG9BYH2@fedora> (raw)
In-Reply-To: <ZJAKTdRVEwZfnKb+@sol>
On Mon Jun 19, 2023 at 9:57 AM CEST, Kent Gibson wrote:
> On Mon, Jun 19, 2023 at 09:36:48AM +0200, Erik Schilling wrote:
> > Sorry, got distracted while sorting out the MSRV mess that I sent a
> > separate patch for [4].
> >
> > I do not think that this is the reason why we need the casts...
> > bindgen generates bindings using std::os::raw::c_uint [5] which is
> > stable since 1.1.0 (and was previously defined as u32 [6]). I think we
> > can just drop the casts entirely? I can run cargo clippy --fix on latest
> > stable (1.70.0), then go back to 1.60 and everything is still building.
> > I am having trouble to execute the tests in that version due to some
> > linkage errors, but that should not be the fault of the casts.
> >
> > Did I got this correct or am I misunderstanding your reasoning?
> >
>
> My reasoning was simply that building the bindings as you suggested
> resulted in lint warnings, which is noisy and iritating when trying to
> lint my own code.
I fully agree that we should fix them! I was just confused about the
explanation.
> But I'm just the messenger. Your question would be better directed at
> Viresh - it is his code so he should be able to tell you why the casts
> are there.
> IIRC we needed the casts historically, though I don't recall the rust
> version we were using at the time.
> If we've moved beyond that then I have no problem with the casts being
> removedi, in fact in my initial comment I lamented the fact they were
> necessary.
ACK. Not sure how the situation was when the patches came together, but
today I would suggest to just drop the casts. Do you want to respin your
series or shall I send the fixes?
> > Note: One needs to fix a bug that cargo clippy --fix introduces since
> > it replaces nth(0) with next() in event_buffers.rs and introduces a
> > unconditional recursion.
> >
>
> Who is using --fix??
I do all the time (and spend the time I saved typing on reviewing)!
(Thought mostly I use the suggested actions suggested by the LSP in
the editor instead of the CLI tools)
> I did put an allow in there for that one, with a comment about the
> recursion, though I'm not sure the comment is sufficiently clear without
> the warning in front of you - and you no longer get that with the allow
> in place.
Ah. Did not notice that... My brain was only thinking about the casts.
- Erik
next prev parent reply other threads:[~2023-06-19 8:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-12 15:40 [libgpiod][PATCH] bindings: rust: fix clippy lint warnings Kent Gibson
2023-06-14 8:14 ` Erik Schilling
2023-06-14 8:29 ` Kent Gibson
2023-06-14 8:40 ` Erik Schilling
2023-06-14 9:06 ` Kent Gibson
2023-06-14 9:16 ` Erik Schilling
2023-06-19 7:36 ` Erik Schilling
2023-06-19 7:49 ` Erik Schilling
2023-06-19 7:57 ` Kent Gibson
2023-06-19 8:13 ` Erik Schilling [this message]
2023-06-19 8:33 ` Kent Gibson
2023-06-19 8:50 ` Viresh Kumar
2023-06-19 8:59 ` Erik Schilling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CTGH61DGZBIQ.RVXF4UG9BYH2@fedora \
--to=erik.schilling@linaro.org \
--cc=brgl@bgdev.pl \
--cc=linux-gpio@vger.kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=warthog618@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.