Suggest handling case insensitivity on .ends_with(".ext")

[kangalio]

What it does

When .ends_with() is called on a String or &str, and the parameter looks like a file extension (regex \.([a-z0-9]{1,5})|([A-Z0-9]{1,5})), inform the programmer that this code will not handle differently-cased filenames well - potentially a bug. Additionally, a correct replacement is suggested (see below).

Categories

• Kind: clippy::pedantic or perhaps clippy::correctness

What is the advantage of the recommended code over the original code

It handles file extensions correctly regardless of case. In Windows, this behavior is very much expected since the entire operating system has case-insensitive filenames. In Linux, filenames are usually case-sensitive, but I think even on Linux, it's standard behavior to recognize file extensions regardless of case.

Drawbacks

• The suggested improvement is harder to read than the naive case-sensitive version
• The line .ends_with(".ext") might not be a file extension check at all. It could mean something else for which case-sensitivity makes sense

Example

if !filename.ends_with(".abc") {
    panic!("Please provide an ABC file");
}

Could be written as:

if filename.rsplit('.').next().map(|ext| ext.eq_ignore_ascii_case("abc")) != Some(true) {
    panic!("Please provide an ABC file");
}

Or like this (nightly-only because of Path::eq_ignore_ascii_case):

let filename = Path::new(filename);
if filename.extension().map(|ext| ext.eq_ignore_ascii_case("abc")) != Some(true) {
    panic!("Please provide an ABC file");
}

[flip1995]

If we should lint this, we should only lint the case, where filename is a Path. If we would also lint strings, this will have too many FPs, I think.

[kangalio]

So like, the lint should trigger only on this kind of thing?

// filename: Path
filename.ends_with(".ext")

Probably nobody is going to write this code, because ends_with on Path doesn't work with the file extension at all. So the above code would fail to return the expected value for almost all inputs, so the programmer will know by themselves that they did something wrong.

The reason for this is that Path::ends_with only considers whole path components to match.

If it would produce too many false positive's to have the lint trigger on strings, I don't think there's any purpose left for this lint suggestion.

[flip1995]

Oh, yeah you're right. Don't know what I was thinking here 😅 Anyway, I would classify this lint as pedantic then and suggest to use the Path methods instead.

[kangalio]

You mean, keep the original proposed behavior of triggering on str::starts_with (as opposed to Path), and classify as pedantic to not annoy regular users with false positives?

[flip1995]

Yes. And if on nightly suggest to convert the string to a path and suggest the path method.

[kadiwa4]

That usage of str::rsplit is misleading, see #9220.