Handle io errors gracefully

[konstin]

Summary

It can happen that we can't read a file (a python file, a jupyter notebook or pyproject.toml), which needs to be handled and handled consistently for all file types. Instead of using Err or error!, we emit E602 with the io error as message and continue. This PR makes sure we handle all three cases consistently, emit E602.

I'm not convinced that it should be possible to disable io errors, but we now handle the regular case consistently and at least print warning consistently.

I went with warn! but i can change them all to error!, too.

It also checks the error case when a pyproject.toml is not readable. The error message is not very helpful, but it's now a bit clearer that actually ruff itself failed instead vs this being a diagnostic.

Examples

This is how an Err of run looks now:

With an unreadable file and IOError disabled:

(we lint zero files but count files before linting not during so we exit 0)

I'm not sure if it should (or if we should take a different path with manual ExitStatus), but this currently also triggers when files is empty:

Test Plan

Unix only: Create a temporary directory with files with permissions 000 (not readable by the owner) and run on that directory. Since this breaks the assumptions of most of the test code (single file, ruff instead of ruff_cli), the test code is rather cumbersome and looks a bit misplaced; i'm happy about suggestions to fit it in closer with the other tests or streamline it in other ways. I added another test for when the entire directory is not readable.

[github-actions]

PR Check Results

Ecosystem

✅ ecosystem check detected no changes.

Benchmark

Linux

group                                      main                                   pr
-----                                      ----                                   --
formatter/large/dataset.py                 1.00      9.3±0.06ms     4.4 MB/sec    1.02      9.5±0.05ms     4.3 MB/sec
formatter/numpy/ctypeslib.py               1.00   1857.7±1.63µs     9.0 MB/sec    1.01   1874.9±2.27µs     8.9 MB/sec
formatter/numpy/globals.py                 1.00    206.9±0.58µs    14.3 MB/sec    1.01    209.4±0.29µs    14.1 MB/sec
formatter/pydantic/types.py                1.00      4.0±0.01ms     6.4 MB/sec    1.01      4.1±0.01ms     6.3 MB/sec
linter/all-rules/large/dataset.py          1.07     14.0±0.12ms     2.9 MB/sec    1.00     13.1±0.09ms     3.1 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.03      3.4±0.01ms     4.8 MB/sec    1.00      3.3±0.05ms     5.0 MB/sec
linter/all-rules/numpy/globals.py          1.03    446.1±0.88µs     6.6 MB/sec    1.00    433.9±0.71µs     6.8 MB/sec
linter/all-rules/pydantic/types.py         1.08      6.4±0.11ms     4.0 MB/sec    1.00      6.0±0.06ms     4.3 MB/sec
linter/default-rules/large/dataset.py      1.13      7.5±0.04ms     5.4 MB/sec    1.00      6.6±0.03ms     6.1 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.11   1555.4±4.39µs    10.7 MB/sec    1.00   1407.0±1.46µs    11.8 MB/sec
linter/default-rules/numpy/globals.py      1.06    165.7±0.22µs    17.8 MB/sec    1.00    155.6±0.36µs    19.0 MB/sec
linter/default-rules/pydantic/types.py     1.12      3.3±0.01ms     7.7 MB/sec    1.00      3.0±0.01ms     8.6 MB/sec

Windows

group                                      main                                   pr
-----                                      ----                                   --
formatter/large/dataset.py                 1.11     16.9±0.73ms     2.4 MB/sec    1.00     15.2±0.60ms     2.7 MB/sec
formatter/numpy/ctypeslib.py               1.07      3.2±0.20ms     5.2 MB/sec    1.00      3.0±0.13ms     5.6 MB/sec
formatter/numpy/globals.py                 1.06   358.9±18.29µs     8.2 MB/sec    1.00   339.2±20.23µs     8.7 MB/sec
formatter/pydantic/types.py                1.04      6.9±0.29ms     3.7 MB/sec    1.00      6.6±0.34ms     3.8 MB/sec
linter/all-rules/large/dataset.py          1.02     22.4±0.79ms  1862.3 KB/sec    1.00     22.0±1.07ms  1893.0 KB/sec
linter/all-rules/numpy/ctypeslib.py        1.04      5.7±0.19ms     2.9 MB/sec    1.00      5.5±0.25ms     3.0 MB/sec
linter/all-rules/numpy/globals.py          1.00   678.4±38.04µs     4.3 MB/sec    1.02   690.7±32.76µs     4.3 MB/sec
linter/all-rules/pydantic/types.py         1.00      9.6±0.34ms     2.6 MB/sec    1.00      9.6±0.43ms     2.6 MB/sec
linter/default-rules/large/dataset.py      1.01     11.8±0.45ms     3.4 MB/sec    1.00     11.7±0.31ms     3.5 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.00      2.4±0.11ms     6.9 MB/sec    1.01      2.4±0.10ms     6.8 MB/sec
linter/default-rules/numpy/globals.py      1.00   283.6±13.14µs    10.4 MB/sec    1.03   292.1±14.79µs    10.1 MB/sec
linter/default-rules/pydantic/types.py     1.00      5.1±0.19ms     5.0 MB/sec    1.02      5.2±0.18ms     4.9 MB/sec

[charliermarsh]

Are these not already treated as IOError via the IOError handling in run.rs? Like this block:

error!(
    "{}{}{} {message}",
    "Failed to lint ".bold(),
    fs::relativize_path(path).bold(),
    ":".bold()
);
let settings = resolver.resolve(path, pyproject_config);
if settings.rules.enabled(Rule::IOError) {
    let file =
        SourceFileBuilder::new(path.to_string_lossy().as_ref(), "").finish();

    Diagnostics::new(
        vec![Message::from_diagnostic(
            Diagnostic::new(IOError { message }, TextRange::default()),
            file,
            TextSize::default(),
        )],
        ImportMap::default(),
    )
} else {
    Diagnostics::default()
}

[charliermarsh]

With this change, do we not lose that warning message that appears separately from the diagnostics?

[konstin]

the diagnostics now check whether IOError is enabled and if it isn't, print a warn! instead (i can change this to an error!, not sure which one is better here). I added another test case for an unreadable directory. There are still cases where we didn't lint any file and still exit 0 because IOError is disabled and/or we count paths before linting instead of after. I added screenshots to the original change description