Update Discv5 version

[njgheorghita]

Fixes #182
Maybe fixes # 186

[njgheorghita]

@carver Ping for thoughts on #186 - I'm a bit baffled as to what's going on with this one. IMO it comes down to the kind of error that's being emitted (ignoring invalid dependency trin-cli which is missing a lib target).

From what I can tell, we're well set up to raise this warning as an error. We have RUSTFLAGS="-D warnings" set in in our ci environment. We even specifically run cargo clippy with --deny warnings. So it seems to me like this warning, which appears to be a rustc warning and not a regular linting warning (which are all raised as errors in our workflow via clippy) should be flagged as an error by cargo.

I've tried a couple other approaches to catch this warning

• Adding a .cargo/config.toml to pass in RUSTFLAGS
• Using #![deny(warnings)] inside crate roots
• Using "-Dwarnings" syntax for RUSTFLAGS which is syntax I've seen used fairly frequently
• Explicitly passing rustflags into cargo RUSTFLAGS="-Dwarnings" cargo build ...

IMO it comes down to us using multiple crates in a workspace. It seems to be a fairly problematic setup for various config / passing rustc settings to cargo (here and here)

Any thoughts as to whether you want me to fix the warning in this pr (by adding a lib.rs) and leave the issue open/closed?

[ogenev]

Any thoughts as to whether you want me to fix the warning in this pr (by adding a lib.rs) and leave the issue open/closed?

I addressed this issue in #209 (sorry for not including it in the PR description). I think removing trin-cli from trin dependencies makes sense because the crate is not a library (no lib.rs file) and trin can't depend on a binary crate.

[njgheorghita]

@ogenev Oh nice, yeah that makes sense to me. I've removed the redundant lib.rs from this pr. Still waiting final confirmation re: open/closing #186 from @carver since the motivation behind the issue was more about generally catching warnings rather than specifically fixing that warning (re discussion here)

[ogenev]

Is this a typo, shouldn't be -D warnings?

[njgheorghita]

I don't believe so. In many of the various blogs/forums I read about this I saw both -D warnings and -Dwarnings used interchangeably as the RUSTFLAGS env variable. But, I've changed it back to its original -D warnings since yeah I'd agree it's more obviously not a typo

[carver]

the motivation behind the issue was more about generally catching warnings rather than specifically fixing that warning (re discussion here)

Yeah, this is definitely the reason for #186, to prevent new warnings to show up. The existing warning was just a convenient way to test that we can configure CI to catch that special type of warning.

So in summary:

1. Don't close Fix build warning #186, since we can't confirm that we can catch warnings in CI
2. 👍🏻 for removing any attempts at flagging warnings, since we can't confirm that they work