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

chore: fix all lints #100

Closed
wants to merge 11 commits into from
Closed

Conversation

eightfilms
Copy link
Contributor

There's a lot of changes - I'll briefly summarize what I did:

I ran, as much as possible, the following:

cargo fix --all --allow-dirty
cargo fmt
cargo clippy --fix --all --allow--dirty

Some parts, I had to manually fix, or was out of scope of the current PR, so I added lint allowances + TODOs instead. An example of such 'out of scope' fixes include the unused_must_uses in r1cs/snarkjs.rs - these would require additional work on error handling which should probably belong in its own PR. For these cases, I prefer lint allowances since they allow us to easily find the spots where we want to fix later on.

Note that some of the lint allowances seem sane, so I didn't add TODOs for those, but only for those I felt would improve code quality if removed.

src/backends/kimchi/asm.rs Outdated Show resolved Hide resolved
@@ -62,6 +62,7 @@ pub struct VerifierIndex {
// Setup
//

#[allow(clippy::type_complexity)]
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess we should create an issue on removing all the #[allow.(.. ^^

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

remove

@@ -1,3 +1,7 @@
// TODO: There is a bunch of places where there are unused vars.
// Remove this lint allowance when fixed.
#![allow(unused_variables)]
Copy link
Contributor

Choose a reason for hiding this comment

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

imo this is dangerous, as these unused variables might be bugs and we should address that instead of silencing it

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Created #101

src/backends/r1cs/mod.rs Outdated Show resolved Hide resolved
src/backends/r1cs/snarkjs.rs Outdated Show resolved Hide resolved
src/backends/r1cs/snarkjs.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@mimoo mimoo left a comment

Choose a reason for hiding this comment

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

mmm, I've always felt like some bugs could be hiding behind the unused variables or unused returned values, so I don't think we should silence them. The compiler warnings should be a daily reminder that we need to address them :D so I propose to not silence anything. I'm happy if this PR is a bunch of benign clippy fixes, but it might be too early to enable clippy in CI

(so I guess, we could have a global issue where people can tackle these one at a time)

@eightfilms
Copy link
Contributor Author

eightfilms commented Jun 6, 2024

@mimoo agreed on compiler warnings being useful to address possible critical bugs, tackling this PR has helped discover these problems. We can hold off on this PR for now and create issues to handle the more important warnings such as the unused results or variables, so that this PR ends up being just simple fixes that are just simple QoL changes.

@mimoo
Copy link
Contributor

mimoo commented Jun 14, 2024

I was thinking, if you remove anything that's not in the scope of this PR, and it contains only easy fixes to clippy, then we can merge it in : o

@eightfilms
Copy link
Contributor Author

eightfilms commented Jun 14, 2024

@mimoo makes sense, I'll remove the ones you mentioned. Seems like the easy fixes are:

  • usage of panic! to assert!
  • doc comments
  • #[must_use] annotations
  • other minor one-time fixes

@mimoo
Copy link
Contributor

mimoo commented Jun 14, 2024

I thought the must_use were false positives? they don't seem correct

bing added 2 commits June 16, 2024 23:35
There's a lot of changes - I'll briefly summarize what I did:

I ran, as much as possible, the following:

```rust
cargo fix --all --allow-dirty
cargo fmt
cargo clippy --fix --all --allow--dirty
```

Some parts, I had to manually fix, or was out of scope of the current PR,
so I added lint allowances + TODOs instead. An example of such 'out of scope'
fixes include the `unused_must_use`s in `r1cs/snarkjs.rs` - these would require
additional work on error handling which should probably belong in its own PR.
For these cases, I prefer lint allowances since they allow us to easily find the spots
where we want to fix later on.

Note that some of the lint allowances seem sane, so I didn't add TODOs for those,
but only for those I felt would improve code quality if removed.
Comment on lines +52 to +62
// TODO: Pass in `String`, instead of `&str`, so we don't hide an
// allocation within.
pub fn new(module: &ModulePath, name: &str) -> Self {
let module = match module {
ModulePath::Local => None,
ModulePath::Alias(_) => unreachable!(),
ModulePath::Absolute(user_repo) => Some(user_repo.clone()),
};
Self {
module,
name: name.clone(),
name: name.to_string(),
Copy link
Contributor Author

Choose a reason for hiding this comment

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

imo name should be passed as a String, so that we don't do a clone internally here.

Comment on lines 34 to 35
// TODO: Fix this by `Box`ing `KimchiVesta`.
#[allow(clippy::large_enum_variant)]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@eightfilms
Copy link
Contributor Author

I did a second pass through after removing all #[must_use] annotations, seems like most of the changes now are trivial changes.

.github/workflows/rust.yml Outdated Show resolved Hide resolved
src/backends/kimchi/mod.rs Outdated Show resolved Hide resolved
let values = values.iter().map(|v| v.pretty()).join(" | ");
let values = values
.iter()
.map(super::super::helpers::PrettyField::pretty)
Copy link
Contributor

Choose a reason for hiding this comment

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

super::super o_O? just use crate::helpers::

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, this was an automatic clippy fix. Changed to PrettyField::pretty

src/backends/kimchi/mod.rs Outdated Show resolved Hide resolved
src/backends/kimchi/mod.rs Outdated Show resolved Hide resolved
src/backends/mod.rs Outdated Show resolved Hide resolved
Span,
) -> Result<Option<Var<B::Field, B::Var>>>;
Copy link
Contributor

Choose a reason for hiding this comment

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

what was the lint here?

@@ -210,7 +210,7 @@ impl<B: Backend> TypeChecker<B> {
}

// `struct.field = <rhs>`
ExprKind::FieldAccess { lhs, rhs } => {
Copy link
Contributor

Choose a reason for hiding this comment

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

removal of variables shouldn't be in this PR as we want to make sure we're not forgetting to do something with them

@@ -13,7 +13,8 @@ use crate::{
};

/// The signature of a hint function
pub type HintFn<B: Backend> = dyn Fn(&B, &mut WitnessEnv<B::Field>) -> Result<B::Field>;
pub type HintFn<B> =
dyn Fn(&B, &mut WitnessEnv<<B as Backend>::Field>) -> Result<<B as Backend>::Field>;
Copy link
Contributor

Choose a reason for hiding this comment

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

same here, I'm not sure I understand this change

@@ -73,7 +73,7 @@ pub fn cmd_build(args: CmdBuild) -> miette::Result<()> {
.path
.unwrap_or_else(|| std::env::current_dir().unwrap().try_into().unwrap());

let (sources, prover_index, verifier_index) = build(&curr_dir, args.asm, args.debug)?;
let (_sources, _prover_index, verifier_index) = build(&curr_dir, args.asm, args.debug)?;
Copy link
Contributor

Choose a reason for hiding this comment

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

pls remove these

@@ -99,7 +98,7 @@ impl PartialEq for AnnotatedCell {

impl PartialOrd for AnnotatedCell {
fn partial_cmp(&self, other: &Self) -> Option<std::cmp::Ordering> {
self.cell.partial_cmp(&other.cell)
Some(self.cmp(other))
Copy link
Contributor

Choose a reason for hiding this comment

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

why move from partial_cmp to cmp?

@eightfilms
Copy link
Contributor Author

@mimoo Got caught up with other matters and left this PR in the dust. I will have time tomorrow to address your comments, sorry!

pub fn generate_witness(
&self,
witness_env: &mut WitnessEnv<B::Field>,
) -> Result<B::GeneratedWitness> {
self.backend.generate_witness(witness_env)
}

#[allow(clippy::type_complexity)]
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd rather not have these allow and be forced to find a way to fix it later

@@ -1,3 +1,7 @@
// TODO: There is a bunch of places where there are unused vars.
// Remove this lint allowance when fixed.
#![allow(unused_variables)]
Copy link
Contributor

Choose a reason for hiding this comment

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

let's remove this

@mimoo
Copy link
Contributor

mimoo commented Jul 16, 2024

sry for reviving this ^^ just pointed out more places that I think we should not fix for now

@mimoo
Copy link
Contributor

mimoo commented Oct 23, 2024

hey sorry but let's pun on this for now, as I think there were too many potentially dangerous changes :o

@mimoo mimoo closed this Oct 23, 2024
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