internal: force use dunce canonicalize

[lijunchen]

No description provided.

[peter-jerry-ye-code-review]

From the provided git diff output, I've identified three notable changes that warrant attention:

1. Addition of clippy.toml:

   • This new file introduces configuration for Clippy, Rust's linter. The specific addition of disallowed-methods with std::path::Path::canonicalize being disallowed suggests a preference for using dunce::canonicalize instead. This change is likely to enforce a more consistent or safer practice across the codebase, especially concerning path canonicalization which can be tricky on different platforms.

2. Usage of dunce::canonicalize in test_cases/mod.rs and expect.rs:

   • The replacement of std::path::Path::canonicalize with dunce::canonicalize in multiple places (specifically in test_cases/mod.rs and expect.rs) directly aligns with the configuration in clippy.toml. This change likely aims to address potential issues with path canonicalization, especially on Windows where UNC paths can cause problems. Using dunce::canonicalize is a known workaround to handle these cases more gracefully.

3. Modification in .justfile for Clippy command:

   • The addition of --locked to the cargo clippy command ensures that the exact dependencies specified in the Cargo.lock file are used. This is a good practice for reproducibility, especially in CI/CD environments where consistency is crucial. It prevents any surprises from newer versions of dependencies introducing changes that could affect the build or the linter results.

Suggestions:

• Consistency Check: Ensure that all instances where std::path::Path::canonicalize is used are updated to use dunce::canonicalize. This will maintain consistency across the codebase and align with the linter configuration.

• Review Impact: Given the introduction of a new linter configuration and changes to canonicalization methods, it might be beneficial to conduct a thorough review or additional testing, especially on Windows, to confirm that these changes do not introduce any unintended side effects.

• Documentation Update: If dunce::canonicalize is preferred over std::path::Path::canonicalize, consider updating documentation or internal coding guidelines to reflect this preference. This will help new developers understand the reasoning behind the choice and encourage consistent practices.

These observations and suggestions should help maintain code quality and ensure that the changes are fully aligned with the project's standards and goals.