Fix lints in rust

[alchemist51]

Description

Currently the native build is not running linter. Did a clippy clean and also added the clippy checks with cargo

Related Issues

Resolves #[Issue number to be closed when this PR is merged]

Check List

• Functionality includes testing.
• API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 No security concerns identified

✅ No TODO sections

🔀 Multiple PR themes Sub-PR theme: Add safety documentation to common FFI functions Relevant files: sandbox/libs/dataformat-native/rust/common/src/error.rs sandbox/libs/dataformat-native/rust/common/src/logger.rs Sub-PR theme: Add safety documentation and fix lints in parquet writer Relevant files: sandbox/plugins/parquet-data-format/src/main/rust/src/ffm.rs sandbox/plugins/parquet-data-format/src/main/rust/src/writer.rs Sub-PR theme: Add Rust clippy check to CI workflow Relevant files: .github/workflows/sandbox-check.yml

⚡ Recommended focus areas for review Documentation Mismatch The comment block starting at line 547 describes cost factors for predicates and collectors, but line 555 begins a new comment about an "Internal scale factor" without proper separation. The original blank line at 554 was removed, making the documentation harder to parse. While not a functional bug, this degrades code readability and may confuse future maintainers about where one concept ends and another begins. /// /// - Predicate = 1: page-stats-only, no I/O, a handful of array lookups. /// - Collector = 10: requires materialising an actual doc-id bitset over /// FFM — posting-list iteration on the Java side, bitset transport + /// RoaringBitmap expansion on the Rust side. Relative cost is /// workload-dependent (Lucene posting iteration is fast for narrow /// queries, slower for wide ones) so "10" is a conservative default. /// Tune (or make config-driven) if profiling shows it matters. /// Internal scale factor for cost computation. All costs are multiplied /// by this so integer division preserves meaningful selectivity differences. /// A predicate keeping 1/8 pages costs `1000 * 1/8 = 125` vs one keeping Unused Import Removal The removal of use std::sync::Arc; at line 32 (old hunk) may cause a compilation error if Arc is used elsewhere in this file but not shown in the diff. If Arc is indeed unused, this is fine. However, if it's used in code outside the visible diff hunks, this change will break the build. Verify that Arc is not referenced anywhere in this file. use datafusion::arrow::datatypes::{DataType, Schema, SchemaRef}; use datafusion::common::tree_node::TreeNode; use datafusion::common::{DFSchema, ScalarValue}; use datafusion::execution::context::ExecutionProps;

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Use inline format string syntax Use inline format string syntax for consistency with other error messages in the codebase. This aligns with the lint fixes applied elsewhere in the PR. sandbox/plugins/parquet-data-format/src/main/rust/src/ffm.rs [124] -let filename = str_from_raw(file_ptr, file_len).map_err(|e| format!("parquet_write: {}", e))?.to_string(); +let filename = str_from_raw(file_ptr, file_len).map_err(|e| format!("parquet_write: {e}"))?.to_string(); Suggestion importance[1-10]: 5 __ Why: The suggestion correctly identifies an inconsistency with the PR's pattern of modernizing format strings to use inline syntax (e.g., {e} instead of {}", e). While this is a valid style improvement that aligns with the rest of the PR changes, it's a minor consistency fix that doesn't impact functionality.	Low

[github-actions]

✅ Gradle check result for 133acdf: SUCCESS

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.43%. Comparing base (5e1e412) to head (133acdf).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #21564      +/-   ##
============================================
+ Coverage     73.37%   73.43%   +0.06%     
- Complexity    74539    74548       +9     
============================================
  Files          5980     5980              
  Lines        338779   338779              
  Branches      48848    48848              
============================================
+ Hits         248577   248795     +218     
+ Misses        70394    70093     -301     
- Partials      19808    19891      +83     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.