Implementing a Simple Linter for Rust Code

This challenge focuses on building a basic static analysis tool for Rust code. Static analysis is crucial for identifying potential errors, style violations, and complex bugs before the code is executed, saving developers significant time and effort. You will implement a simple linter that checks for a specific common anti-pattern in Rust.

Problem Description

Your task is to create a Rust program that acts as a simple linter for Rust source code. This linter will analyze a given Rust source file and identify instances of a specific anti-pattern: using unwrap() on a Result type without checking for an error.

This pattern is often a source of panics in Rust applications. While unwrap() has its place, overuse or careless use can lead to unexpected program termination. Your linter should flag these occurrences, providing the line number where they appear.

Key Requirements:

• The program should accept a path to a Rust source file as a command-line argument.
• It needs to parse the Rust code to understand its structure.
• It should identify all occurrences of .unwrap() that are called on a Result type.
• For each identified instance, it should report the line number and a descriptive message.
• The program should handle files that may not exist or are not valid Rust code gracefully.

Expected Behavior:

The linter should print a list of issues it finds. If no issues are found, it should indicate that the code is clean (or simply print nothing).

Edge Cases to Consider:

• Files that don't exist.
• Files with syntax errors that prevent parsing.
• .unwrap() being used on non-Result types (e.g., on an Option or a custom type). Your linter should only flag unwrap() on Result.
• unwrap() being part of a larger expression or macro that doesn't directly apply to a Result.

Examples

Example 1:

Input File (good_code.rs):

fn main() {
    let result: Result<i32, &str> = Ok(5);
    match result {
        Ok(value) => println!("Success: {}", value),
        Err(e) => println!("Error: {}", e),
    }
}

Output: (No output, as there are no unwrap() calls on Result)

Example 2:

Input File (bad_code.rs):

fn main() {
    let result1: Result<i32, &str> = Ok(5);
    let value1 = result1.unwrap(); // Line 3
    println!("Value 1: {}", value1);

    let result2: Result<String, std::io::Error> = std::fs::read_to_string("non_existent.txt");
    let content = result2.unwrap(); // Line 7
    println!("Content: {}", content);
}

Output:

bad_code.rs:3:19: error: Potential panic: using unwrap() on a Result without checking for errors.
bad_code.rs:7:17: error: Potential panic: using unwrap() on a Result without checking for errors.

Example 3:

Input File (mixed_code.rs):

fn main() {
    let option_val: Option<i32> = Some(10);
    let unwrapped_option = option_val.unwrap(); // This should NOT be flagged.

    let result: Result<i32, &str> = Err("Something went wrong");
    let unwrapped_result = result.unwrap(); // Line 6
    println!("This will panic: {}", unwrapped_result);
}

Output:

mixed_code.rs:6:24: error: Potential panic: using unwrap() on a Result without checking for errors.

Constraints

• The input will be a valid or invalid path to a file.
• The file content will be text.
• Performance is not a primary concern for this challenge, but excessively inefficient parsing (e.g., reading the file line by line and doing complex string matching) should be avoided.

Notes

This challenge requires you to interact with the Rust compiler's abstract syntax tree (AST). The syn crate is an excellent choice for parsing Rust code into an AST, and quote can be useful for generating code if you were to extend this to a procedural macro. You'll likely want to explore syn::visit to traverse the AST and identify the relevant patterns.

Consider how you will differentiate between .unwrap() called on Result and other types. You might need to leverage type information if available through the AST, or make simplifying assumptions for this specific challenge. For this problem, a pragmatic approach focusing on the .unwrap() method call on expressions that look like Results would be a good starting point.