ARROW-9980: [Rust] [Parquet] Fix clippy lints by nevi-me · Pull Request #8173 · apache/arrow

nevi-me · 2020-09-12T15:23:52Z

This is a followup of https://issues.apache.org/jira/browse/ARROW-9979

github-actions · 2020-09-12T15:31:53Z

https://issues.apache.org/jira/browse/ARROW-9980

After disabling some pendantic lints and addressing more, we have <20 warnings & errors

jhorstmann · 2020-09-12T17:12:41Z

 fn test_primitive_array_float_sum() {
 let a = Float64Array::from(vec![1.1, 2.2, 3.3, 4.4, 5.5]);
-assert_eq!(16.5, sum(&a).unwrap());
+assert!(16.5 - sum(&a).unwrap() < f64::EPSILON);


I had a bit of a disagreement with a coworker about this clippy warning before and would like to hear your opinion. IMO in most of those tests (especially casts, or when the inputs don't have a fractional part) we are expecting an exact value, not something close to that value. Writing the assertion like that makes the tests harder to read and also would make me wonder in which circumstances the kernel would do some rounding.
Some tests like this could also be rewritten such that all input number can be exactly represented in floating point, following a pattern like x/(2^y), for example 1.125 or 2.25.

If it is about readability, perhaps we can define a macro like assert_float_eq and wrap this logic inside?

The results could vary depending on the hardware we are running on. For now, we are assuming that everything is running on CPU but there is no reason why we couldn't have GPU versions of these kernels in the future, and there could be differences in precision in this case.
https://docs.nvidia.com/cuda/floating-point/index.html

I like the approach of a macro, we can add it in a follow-up

Readability in the sense of understanding the intent of a test. Reading a test should help understand the specified behaviour of some code. So when I'm reading a test that asserts with an epsilon while the ieee 754 standard promises an exact result for those inputs, I'm wondering why the implementation is allowed to have such imprecision. That applies especially to the cast kernels, 3 as f64 should be exactly 3.0, an implementation returning 2.999999... should fail that testcase.
Note I'm talking about unit tests of simple operations with small known inputs and outputs. For more complex (nested, or trigonometric) operations assertions with some epsilon are totally fine, but then the epsilon also depends on the scale of the inputs and f64::EPSILON is a bit of an arbitrary choice.
Instead of replacing all floating point assertions with a macro I would propose to look through those tests and decide whether the result is expected to be an exact match, and then either use #[allow(clippy::float_cmp)] or two different assert macros for exact/with epsilon.

I can do this in the coming 2 weeks. I would agree with the approach of turning off the lint where it matters, which I think would be almost all cases.
I had to merge this PR to bank the time (spent much of the Saturday working on this instead of a lot of other work) and because I already have 2 other PRs that I decided to prepare on top of the clippy lints

nevi-me · 2020-09-12T15:23:52Z

This is a followup of https://issues.apache.org/jira/browse/ARROW-9979

github-actions · 2020-09-12T15:31:53Z

https://issues.apache.org/jira/browse/ARROW-9980

After disabling some pendantic lints and addressing more, we have <20 warnings & errors

jhorstmann · 2020-09-12T17:12:41Z

 fn test_primitive_array_float_sum() {
 let a = Float64Array::from(vec![1.1, 2.2, 3.3, 4.4, 5.5]);
-assert_eq!(16.5, sum(&a).unwrap());
+assert!(16.5 - sum(&a).unwrap() < f64::EPSILON);


I had a bit of a disagreement with a coworker about this clippy warning before and would like to hear your opinion. IMO in most of those tests (especially casts, or when the inputs don't have a fractional part) we are expecting an exact value, not something close to that value. Writing the assertion like that makes the tests harder to read and also would make me wonder in which circumstances the kernel would do some rounding.
Some tests like this could also be rewritten such that all input number can be exactly represented in floating point, following a pattern like x/(2^y), for example 1.125 or 2.25.

If it is about readability, perhaps we can define a macro like assert_float_eq and wrap this logic inside?

The results could vary depending on the hardware we are running on. For now, we are assuming that everything is running on CPU but there is no reason why we couldn't have GPU versions of these kernels in the future, and there could be differences in precision in this case.
https://docs.nvidia.com/cuda/floating-point/index.html

I like the approach of a macro, we can add it in a follow-up

Readability in the sense of understanding the intent of a test. Reading a test should help understand the specified behaviour of some code. So when I'm reading a test that asserts with an epsilon while the ieee 754 standard promises an exact result for those inputs, I'm wondering why the implementation is allowed to have such imprecision. That applies especially to the cast kernels, 3 as f64 should be exactly 3.0, an implementation returning 2.999999... should fail that testcase.
Note I'm talking about unit tests of simple operations with small known inputs and outputs. For more complex (nested, or trigonometric) operations assertions with some epsilon are totally fine, but then the epsilon also depends on the scale of the inputs and f64::EPSILON is a bit of an arbitrary choice.
Instead of replacing all floating point assertions with a macro I would propose to look through those tests and decide whether the result is expected to be an exact match, and then either use #[allow(clippy::float_cmp)] or two different assert macros for exact/with epsilon.

I can do this in the coming 2 weeks. I would agree with the approach of turning off the lint where it matters, which I think would be almost all cases.
I had to merge this PR to bank the time (spent much of the Saturday working on this instead of a lot of other work) and because I already have 2 other PRs that I decided to prepare on top of the clippy lints

nevi-me · 2020-09-12T15:23:52Z

This is a followup of https://issues.apache.org/jira/browse/ARROW-9979

github-actions · 2020-09-12T15:31:53Z

https://issues.apache.org/jira/browse/ARROW-9980

After disabling some pendantic lints and addressing more, we have <20 warnings & errors

jhorstmann · 2020-09-12T17:12:41Z

 fn test_primitive_array_float_sum() {
 let a = Float64Array::from(vec![1.1, 2.2, 3.3, 4.4, 5.5]);
-assert_eq!(16.5, sum(&a).unwrap());
+assert!(16.5 - sum(&a).unwrap() < f64::EPSILON);


I had a bit of a disagreement with a coworker about this clippy warning before and would like to hear your opinion. IMO in most of those tests (especially casts, or when the inputs don't have a fractional part) we are expecting an exact value, not something close to that value. Writing the assertion like that makes the tests harder to read and also would make me wonder in which circumstances the kernel would do some rounding.
Some tests like this could also be rewritten such that all input number can be exactly represented in floating point, following a pattern like x/(2^y), for example 1.125 or 2.25.

If it is about readability, perhaps we can define a macro like assert_float_eq and wrap this logic inside?

The results could vary depending on the hardware we are running on. For now, we are assuming that everything is running on CPU but there is no reason why we couldn't have GPU versions of these kernels in the future, and there could be differences in precision in this case.
https://docs.nvidia.com/cuda/floating-point/index.html

I like the approach of a macro, we can add it in a follow-up

Readability in the sense of understanding the intent of a test. Reading a test should help understand the specified behaviour of some code. So when I'm reading a test that asserts with an epsilon while the ieee 754 standard promises an exact result for those inputs, I'm wondering why the implementation is allowed to have such imprecision. That applies especially to the cast kernels, 3 as f64 should be exactly 3.0, an implementation returning 2.999999... should fail that testcase.
Note I'm talking about unit tests of simple operations with small known inputs and outputs. For more complex (nested, or trigonometric) operations assertions with some epsilon are totally fine, but then the epsilon also depends on the scale of the inputs and f64::EPSILON is a bit of an arbitrary choice.
Instead of replacing all floating point assertions with a macro I would propose to look through those tests and decide whether the result is expected to be an exact match, and then either use #[allow(clippy::float_cmp)] or two different assert macros for exact/with epsilon.

I can do this in the coming 2 weeks. I would agree with the approach of turning off the lint where it matters, which I think would be almost all cases.
I had to merge this PR to bank the time (spent much of the Saturday working on this instead of a lot of other work) and because I already have 2 other PRs that I decided to prepare on top of the clippy lints

nevi-me · 2020-09-12T15:23:52Z

This is a followup of https://issues.apache.org/jira/browse/ARROW-9979

github-actions · 2020-09-12T15:31:53Z

https://issues.apache.org/jira/browse/ARROW-9980

After disabling some pendantic lints and addressing more, we have <20 warnings & errors

jhorstmann · 2020-09-12T17:12:41Z

 fn test_primitive_array_float_sum() {
 let a = Float64Array::from(vec![1.1, 2.2, 3.3, 4.4, 5.5]);
-assert_eq!(16.5, sum(&a).unwrap());
+assert!(16.5 - sum(&a).unwrap() < f64::EPSILON);


I had a bit of a disagreement with a coworker about this clippy warning before and would like to hear your opinion. IMO in most of those tests (especially casts, or when the inputs don't have a fractional part) we are expecting an exact value, not something close to that value. Writing the assertion like that makes the tests harder to read and also would make me wonder in which circumstances the kernel would do some rounding.
Some tests like this could also be rewritten such that all input number can be exactly represented in floating point, following a pattern like x/(2^y), for example 1.125 or 2.25.

If it is about readability, perhaps we can define a macro like assert_float_eq and wrap this logic inside?

The results could vary depending on the hardware we are running on. For now, we are assuming that everything is running on CPU but there is no reason why we couldn't have GPU versions of these kernels in the future, and there could be differences in precision in this case.
https://docs.nvidia.com/cuda/floating-point/index.html

I like the approach of a macro, we can add it in a follow-up

Readability in the sense of understanding the intent of a test. Reading a test should help understand the specified behaviour of some code. So when I'm reading a test that asserts with an epsilon while the ieee 754 standard promises an exact result for those inputs, I'm wondering why the implementation is allowed to have such imprecision. That applies especially to the cast kernels, 3 as f64 should be exactly 3.0, an implementation returning 2.999999... should fail that testcase.
Note I'm talking about unit tests of simple operations with small known inputs and outputs. For more complex (nested, or trigonometric) operations assertions with some epsilon are totally fine, but then the epsilon also depends on the scale of the inputs and f64::EPSILON is a bit of an arbitrary choice.
Instead of replacing all floating point assertions with a macro I would propose to look through those tests and decide whether the result is expected to be an exact match, and then either use #[allow(clippy::float_cmp)] or two different assert macros for exact/with epsilon.

I can do this in the coming 2 weeks. I would agree with the approach of turning off the lint where it matters, which I think would be almost all cases.
I had to merge this PR to bank the time (spent much of the Saturday working on this instead of a lot of other work) and because I already have 2 other PRs that I decided to prepare on top of the clippy lints

nevi-me · 2020-09-12T15:23:52Z

This is a followup of https://issues.apache.org/jira/browse/ARROW-9979

github-actions · 2020-09-12T15:31:53Z

https://issues.apache.org/jira/browse/ARROW-9980

After disabling some pendantic lints and addressing more, we have <20 warnings & errors

jhorstmann · 2020-09-12T17:12:41Z

 fn test_primitive_array_float_sum() {
 let a = Float64Array::from(vec![1.1, 2.2, 3.3, 4.4, 5.5]);
-assert_eq!(16.5, sum(&a).unwrap());
+assert!(16.5 - sum(&a).unwrap() < f64::EPSILON);


I had a bit of a disagreement with a coworker about this clippy warning before and would like to hear your opinion. IMO in most of those tests (especially casts, or when the inputs don't have a fractional part) we are expecting an exact value, not something close to that value. Writing the assertion like that makes the tests harder to read and also would make me wonder in which circumstances the kernel would do some rounding.
Some tests like this could also be rewritten such that all input number can be exactly represented in floating point, following a pattern like x/(2^y), for example 1.125 or 2.25.

If it is about readability, perhaps we can define a macro like assert_float_eq and wrap this logic inside?

The results could vary depending on the hardware we are running on. For now, we are assuming that everything is running on CPU but there is no reason why we couldn't have GPU versions of these kernels in the future, and there could be differences in precision in this case.
https://docs.nvidia.com/cuda/floating-point/index.html

I like the approach of a macro, we can add it in a follow-up

Readability in the sense of understanding the intent of a test. Reading a test should help understand the specified behaviour of some code. So when I'm reading a test that asserts with an epsilon while the ieee 754 standard promises an exact result for those inputs, I'm wondering why the implementation is allowed to have such imprecision. That applies especially to the cast kernels, 3 as f64 should be exactly 3.0, an implementation returning 2.999999... should fail that testcase.
Note I'm talking about unit tests of simple operations with small known inputs and outputs. For more complex (nested, or trigonometric) operations assertions with some epsilon are totally fine, but then the epsilon also depends on the scale of the inputs and f64::EPSILON is a bit of an arbitrary choice.
Instead of replacing all floating point assertions with a macro I would propose to look through those tests and decide whether the result is expected to be an exact match, and then either use #[allow(clippy::float_cmp)] or two different assert macros for exact/with epsilon.

I can do this in the coming 2 weeks. I would agree with the approach of turning off the lint where it matters, which I think would be almost all cases.
I had to merge this PR to bank the time (spent much of the Saturday working on this instead of a lot of other work) and because I already have 2 other PRs that I decided to prepare on top of the clippy lints

nevi-me · 2020-09-12T15:23:52Z

This is a followup of https://issues.apache.org/jira/browse/ARROW-9979

github-actions · 2020-09-12T15:31:53Z

https://issues.apache.org/jira/browse/ARROW-9980

After disabling some pendantic lints and addressing more, we have <20 warnings & errors

jhorstmann · 2020-09-12T17:12:41Z

 fn test_primitive_array_float_sum() {
 let a = Float64Array::from(vec![1.1, 2.2, 3.3, 4.4, 5.5]);
-assert_eq!(16.5, sum(&a).unwrap());
+assert!(16.5 - sum(&a).unwrap() < f64::EPSILON);


I had a bit of a disagreement with a coworker about this clippy warning before and would like to hear your opinion. IMO in most of those tests (especially casts, or when the inputs don't have a fractional part) we are expecting an exact value, not something close to that value. Writing the assertion like that makes the tests harder to read and also would make me wonder in which circumstances the kernel would do some rounding.
Some tests like this could also be rewritten such that all input number can be exactly represented in floating point, following a pattern like x/(2^y), for example 1.125 or 2.25.

If it is about readability, perhaps we can define a macro like assert_float_eq and wrap this logic inside?

The results could vary depending on the hardware we are running on. For now, we are assuming that everything is running on CPU but there is no reason why we couldn't have GPU versions of these kernels in the future, and there could be differences in precision in this case.
https://docs.nvidia.com/cuda/floating-point/index.html

I like the approach of a macro, we can add it in a follow-up

Readability in the sense of understanding the intent of a test. Reading a test should help understand the specified behaviour of some code. So when I'm reading a test that asserts with an epsilon while the ieee 754 standard promises an exact result for those inputs, I'm wondering why the implementation is allowed to have such imprecision. That applies especially to the cast kernels, 3 as f64 should be exactly 3.0, an implementation returning 2.999999... should fail that testcase.
Note I'm talking about unit tests of simple operations with small known inputs and outputs. For more complex (nested, or trigonometric) operations assertions with some epsilon are totally fine, but then the epsilon also depends on the scale of the inputs and f64::EPSILON is a bit of an arbitrary choice.
Instead of replacing all floating point assertions with a macro I would propose to look through those tests and decide whether the result is expected to be an exact match, and then either use #[allow(clippy::float_cmp)] or two different assert macros for exact/with epsilon.

I can do this in the coming 2 weeks. I would agree with the approach of turning off the lint where it matters, which I think would be almost all cases.
I had to merge this PR to bank the time (spent much of the Saturday working on this instead of a lot of other work) and because I already have 2 other PRs that I decided to prepare on top of the clippy lints

nevi-me · 2020-09-12T15:23:52Z

This is a followup of https://issues.apache.org/jira/browse/ARROW-9979

github-actions · 2020-09-12T15:31:53Z

https://issues.apache.org/jira/browse/ARROW-9980

After disabling some pendantic lints and addressing more, we have <20 warnings & errors

jhorstmann · 2020-09-12T17:12:41Z

 fn test_primitive_array_float_sum() {
 let a = Float64Array::from(vec![1.1, 2.2, 3.3, 4.4, 5.5]);
-assert_eq!(16.5, sum(&a).unwrap());
+assert!(16.5 - sum(&a).unwrap() < f64::EPSILON);


I had a bit of a disagreement with a coworker about this clippy warning before and would like to hear your opinion. IMO in most of those tests (especially casts, or when the inputs don't have a fractional part) we are expecting an exact value, not something close to that value. Writing the assertion like that makes the tests harder to read and also would make me wonder in which circumstances the kernel would do some rounding.
Some tests like this could also be rewritten such that all input number can be exactly represented in floating point, following a pattern like x/(2^y), for example 1.125 or 2.25.

If it is about readability, perhaps we can define a macro like assert_float_eq and wrap this logic inside?

The results could vary depending on the hardware we are running on. For now, we are assuming that everything is running on CPU but there is no reason why we couldn't have GPU versions of these kernels in the future, and there could be differences in precision in this case.
https://docs.nvidia.com/cuda/floating-point/index.html

I like the approach of a macro, we can add it in a follow-up

Readability in the sense of understanding the intent of a test. Reading a test should help understand the specified behaviour of some code. So when I'm reading a test that asserts with an epsilon while the ieee 754 standard promises an exact result for those inputs, I'm wondering why the implementation is allowed to have such imprecision. That applies especially to the cast kernels, 3 as f64 should be exactly 3.0, an implementation returning 2.999999... should fail that testcase.
Note I'm talking about unit tests of simple operations with small known inputs and outputs. For more complex (nested, or trigonometric) operations assertions with some epsilon are totally fine, but then the epsilon also depends on the scale of the inputs and f64::EPSILON is a bit of an arbitrary choice.
Instead of replacing all floating point assertions with a macro I would propose to look through those tests and decide whether the result is expected to be an exact match, and then either use #[allow(clippy::float_cmp)] or two different assert macros for exact/with epsilon.

I can do this in the coming 2 weeks. I would agree with the approach of turning off the lint where it matters, which I think would be almost all cases.
I had to merge this PR to bank the time (spent much of the Saturday working on this instead of a lot of other work) and because I already have 2 other PRs that I decided to prepare on top of the clippy lints

nevi-me · 2020-09-12T15:23:52Z

This is a followup of https://issues.apache.org/jira/browse/ARROW-9979

github-actions · 2020-09-12T15:31:53Z

https://issues.apache.org/jira/browse/ARROW-9980

After disabling some pendantic lints and addressing more, we have <20 warnings & errors

jhorstmann · 2020-09-12T17:12:41Z

 fn test_primitive_array_float_sum() {
 let a = Float64Array::from(vec![1.1, 2.2, 3.3, 4.4, 5.5]);
-assert_eq!(16.5, sum(&a).unwrap());
+assert!(16.5 - sum(&a).unwrap() < f64::EPSILON);


I had a bit of a disagreement with a coworker about this clippy warning before and would like to hear your opinion. IMO in most of those tests (especially casts, or when the inputs don't have a fractional part) we are expecting an exact value, not something close to that value. Writing the assertion like that makes the tests harder to read and also would make me wonder in which circumstances the kernel would do some rounding.
Some tests like this could also be rewritten such that all input number can be exactly represented in floating point, following a pattern like x/(2^y), for example 1.125 or 2.25.

If it is about readability, perhaps we can define a macro like assert_float_eq and wrap this logic inside?

The results could vary depending on the hardware we are running on. For now, we are assuming that everything is running on CPU but there is no reason why we couldn't have GPU versions of these kernels in the future, and there could be differences in precision in this case.
https://docs.nvidia.com/cuda/floating-point/index.html

I like the approach of a macro, we can add it in a follow-up

Readability in the sense of understanding the intent of a test. Reading a test should help understand the specified behaviour of some code. So when I'm reading a test that asserts with an epsilon while the ieee 754 standard promises an exact result for those inputs, I'm wondering why the implementation is allowed to have such imprecision. That applies especially to the cast kernels, 3 as f64 should be exactly 3.0, an implementation returning 2.999999... should fail that testcase.
Note I'm talking about unit tests of simple operations with small known inputs and outputs. For more complex (nested, or trigonometric) operations assertions with some epsilon are totally fine, but then the epsilon also depends on the scale of the inputs and f64::EPSILON is a bit of an arbitrary choice.
Instead of replacing all floating point assertions with a macro I would propose to look through those tests and decide whether the result is expected to be an exact match, and then either use #[allow(clippy::float_cmp)] or two different assert macros for exact/with epsilon.

I can do this in the coming 2 weeks. I would agree with the approach of turning off the lint where it matters, which I think would be almost all cases.
I had to merge this PR to bank the time (spent much of the Saturday working on this instead of a lot of other work) and because I already have 2 other PRs that I decided to prepare on top of the clippy lints

nevi-me requested review from paddyhoran and sunchao September 12, 2020 15:23

andygrove added the Component: Rust label Sep 12, 2020

nevi-me added 4 commits September 12, 2020 18:37

arrow clippy fixes
a80693c

fix variable in examples
0d50898

parquet clippy lints
0986881

fix tests, more lint fixes
9da75b5
After disabling some pendantic lints and addressing more, we have <20 warnings & errors

nevi-me force-pushed the clippy-fixes-parquet-sep2020 branch from 3cd378c to 9da75b5Compare September 12, 2020 16:40

andygrove approved these changes Sep 12, 2020
View reviewed changes

jhorstmann reviewed Sep 12, 2020
View reviewed changes

sunchao approved these changes Sep 12, 2020
View reviewed changes

nevi-me closed this in c6994f1Sep 12, 2020

nevi-me deleted the clippy-fixes-parquet-sep2020 branch January 5, 2021 19:12

asfimport mentioned this pull request Sep 12, 2020
[Rust] Fix parquet crate clippy lints #17344
Closed

nevi-me requested review from paddyhoran and sunchao September 12, 2020 15:23

andygrove added the Component: Rust label Sep 12, 2020

nevi-me added 4 commits September 12, 2020 18:37

arrow clippy fixes
a80693c

fix variable in examples
0d50898

parquet clippy lints
0986881

fix tests, more lint fixes
9da75b5
After disabling some pendantic lints and addressing more, we have <20 warnings & errors

nevi-me force-pushed the clippy-fixes-parquet-sep2020 branch from 3cd378c to 9da75b5Compare September 12, 2020 16:40

andygrove approved these changes Sep 12, 2020
View reviewed changes

jhorstmann reviewed Sep 12, 2020
View reviewed changes

sunchao approved these changes Sep 12, 2020
View reviewed changes

nevi-me closed this in c6994f1Sep 12, 2020

nevi-me deleted the clippy-fixes-parquet-sep2020 branch January 5, 2021 19:12

asfimport mentioned this pull request Sep 12, 2020
[Rust] Fix parquet crate clippy lints #17344
Closed

nevi-me requested review from paddyhoran and sunchao September 12, 2020 15:23

andygrove added the Component: Rust label Sep 12, 2020

nevi-me added 4 commits September 12, 2020 18:37

arrow clippy fixes
a80693c

fix variable in examples
0d50898

parquet clippy lints
0986881

fix tests, more lint fixes
9da75b5
After disabling some pendantic lints and addressing more, we have <20 warnings & errors

nevi-me force-pushed the clippy-fixes-parquet-sep2020 branch from 3cd378c to 9da75b5Compare September 12, 2020 16:40

andygrove approved these changes Sep 12, 2020
View reviewed changes

jhorstmann reviewed Sep 12, 2020
View reviewed changes

sunchao approved these changes Sep 12, 2020
View reviewed changes

nevi-me closed this in c6994f1Sep 12, 2020

nevi-me deleted the clippy-fixes-parquet-sep2020 branch January 5, 2021 19:12

asfimport mentioned this pull request Sep 12, 2020
[Rust] Fix parquet crate clippy lints #17344
Closed

nevi-me requested review from paddyhoran and sunchao September 12, 2020 15:23

andygrove added the Component: Rust label Sep 12, 2020

nevi-me added 4 commits September 12, 2020 18:37

arrow clippy fixes
a80693c

fix variable in examples
0d50898

parquet clippy lints
0986881

fix tests, more lint fixes
9da75b5
After disabling some pendantic lints and addressing more, we have <20 warnings & errors

nevi-me force-pushed the clippy-fixes-parquet-sep2020 branch from 3cd378c to 9da75b5Compare September 12, 2020 16:40

andygrove approved these changes Sep 12, 2020
View reviewed changes

jhorstmann reviewed Sep 12, 2020
View reviewed changes

sunchao approved these changes Sep 12, 2020
View reviewed changes

nevi-me closed this in c6994f1Sep 12, 2020

nevi-me deleted the clippy-fixes-parquet-sep2020 branch January 5, 2021 19:12

asfimport mentioned this pull request Sep 12, 2020
[Rust] Fix parquet crate clippy lints #17344
Closed

nevi-me requested review from paddyhoran and sunchao September 12, 2020 15:23

andygrove added the Component: Rust label Sep 12, 2020

nevi-me added 4 commits September 12, 2020 18:37

arrow clippy fixes
a80693c

fix variable in examples
0d50898

parquet clippy lints
0986881

fix tests, more lint fixes
9da75b5
After disabling some pendantic lints and addressing more, we have <20 warnings & errors

nevi-me force-pushed the clippy-fixes-parquet-sep2020 branch from 3cd378c to 9da75b5Compare September 12, 2020 16:40

andygrove approved these changes Sep 12, 2020
View reviewed changes

jhorstmann reviewed Sep 12, 2020
View reviewed changes

sunchao approved these changes Sep 12, 2020
View reviewed changes

nevi-me closed this in c6994f1Sep 12, 2020

nevi-me deleted the clippy-fixes-parquet-sep2020 branch January 5, 2021 19:12

asfimport mentioned this pull request Sep 12, 2020
[Rust] Fix parquet crate clippy lints #17344
Closed

nevi-me requested review from paddyhoran and sunchao September 12, 2020 15:23

andygrove added the Component: Rust label Sep 12, 2020

nevi-me added 4 commits September 12, 2020 18:37

arrow clippy fixes
a80693c

fix variable in examples
0d50898

parquet clippy lints
0986881

fix tests, more lint fixes
9da75b5
After disabling some pendantic lints and addressing more, we have <20 warnings & errors

nevi-me force-pushed the clippy-fixes-parquet-sep2020 branch from 3cd378c to 9da75b5Compare September 12, 2020 16:40

andygrove approved these changes Sep 12, 2020
View reviewed changes

jhorstmann reviewed Sep 12, 2020
View reviewed changes

sunchao approved these changes Sep 12, 2020
View reviewed changes

nevi-me closed this in c6994f1Sep 12, 2020

nevi-me deleted the clippy-fixes-parquet-sep2020 branch January 5, 2021 19:12

asfimport mentioned this pull request Sep 12, 2020
[Rust] Fix parquet crate clippy lints #17344
Closed

nevi-me requested review from paddyhoran and sunchao September 12, 2020 15:23

andygrove added the Component: Rust label Sep 12, 2020

nevi-me added 4 commits September 12, 2020 18:37

arrow clippy fixes
a80693c

fix variable in examples
0d50898

parquet clippy lints
0986881

fix tests, more lint fixes
9da75b5
After disabling some pendantic lints and addressing more, we have <20 warnings & errors

nevi-me force-pushed the clippy-fixes-parquet-sep2020 branch from 3cd378c to 9da75b5Compare September 12, 2020 16:40

andygrove approved these changes Sep 12, 2020
View reviewed changes

jhorstmann reviewed Sep 12, 2020
View reviewed changes

sunchao approved these changes Sep 12, 2020
View reviewed changes

nevi-me closed this in c6994f1Sep 12, 2020

nevi-me deleted the clippy-fixes-parquet-sep2020 branch January 5, 2021 19:12

asfimport mentioned this pull request Sep 12, 2020
[Rust] Fix parquet crate clippy lints #17344
Closed

nevi-me requested review from paddyhoran and sunchao September 12, 2020 15:23

andygrove added the Component: Rust label Sep 12, 2020

nevi-me added 4 commits September 12, 2020 18:37

arrow clippy fixes
a80693c

fix variable in examples
0d50898

parquet clippy lints
0986881

fix tests, more lint fixes
9da75b5
After disabling some pendantic lints and addressing more, we have <20 warnings & errors

nevi-me force-pushed the clippy-fixes-parquet-sep2020 branch from 3cd378c to 9da75b5Compare September 12, 2020 16:40

andygrove approved these changes Sep 12, 2020
View reviewed changes

jhorstmann reviewed Sep 12, 2020
View reviewed changes

sunchao approved these changes Sep 12, 2020
View reviewed changes

nevi-me closed this in c6994f1Sep 12, 2020

nevi-me deleted the clippy-fixes-parquet-sep2020 branch January 5, 2021 19:12

asfimport mentioned this pull request Sep 12, 2020
[Rust] Fix parquet crate clippy lints #17344
Closed

Uh oh!

Conversation

nevi-me commented Sep 12, 2020

Uh oh!

github-actionsBot commented Sep 12, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nevi-meSep 12, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

nevi-me commented Sep 12, 2020

Uh oh!

github-actionsBot commented Sep 12, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nevi-meSep 12, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

nevi-me commented Sep 12, 2020

Uh oh!

github-actionsBot commented Sep 12, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nevi-meSep 12, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

nevi-meSep 12, 2020•
edited
Loading

nevi-meSep 12, 2020•
edited
Loading

nevi-meSep 12, 2020•
edited
Loading

nevi-meSep 12, 2020•
edited
Loading