Do not warn about similar ASCII-only idents

[pyfisch]

See discussion at rust-lang/rust#55467 (comment) ff.

Rename less_used_codepoints to uncommon_codepoints (rust-lang/rust#55467 (comment))

cc @crlf0710

[pyfisch]

One caveat of ignoring ASCII-only identifiers is that the compiler still warns about mixed script identifiers with a potentially confusable ASCII character. By this metric person_e1 and person_el are not confusable but 人_e1 and 人_el are confusable.

[crlf0710]

Looks great.

By the way, another unsolved question:

In mixed_script_confusables, do we actually need to make an exception for Latin identifiers?

Reading the actual generated table, the answer is also clearly 'yes', i think.

The mixed script confusable alphabet for ascii latin is:
ABCEHIJKMNOPSTUVWXYZ
abcefghijlnopqrsuvwxy

and a single lib.rs with pub fn foo() {} will trigger the mixed_script_confusable lint if the exception is not made.

cc @Manishearth

[Manishearth]

@crlf0710 that table seems incorrectly generated.

[Manishearth]

oh, never mind

[Manishearth]

Yes, we need a Latin exception, because the stdlib is Latin. The RFC states this outright.

[pyfisch]

Should I just remove the (un)resolved question about mixed_script_confusables?

[Manishearth]

No, that's not how unresolved questions work, we resolve them in the tracking issue if necessary.

[crlf0710]

Implementation adjustment is ready at rust-lang/rust#72069

[joshtriplett]

One caveat of ignoring ASCII-only identifiers is that the compiler still warns about mixed script identifiers with a potentially confusable ASCII character. By this metric person_e1 and person_el are not confusable but 人_e1 and 人_el are confusable.

Is there some way we can implement the notion that the actual confusable characters must be from different scripts?

[Manishearth]

That's already in the RFC in the heuristics for mixed_script_confusables

[pickfire]

One caveat of ignoring ASCII-only identifiers is that the compiler still warns about mixed script identifiers with a potentially confusable ASCII character. By this metric person_e1 and person_el are not confusable but 人_e1 and 人_el are confusable.

Aren't them the same? Person and 人 have the same meaning but there is no easy way to write el or e1 in Chinese or Japanese. So a mix of characters is still likely needed, such as 人1 or 人2, it would be weird to see 人一 or 人二.

I don't know if writing variables in non-latin would be helpful but a mix for numeric might be needed.

[Manishearth]

Aren't them the same?

No, one is rén + the letter e + the number 1, the other is rén + the letter e + the lowercase letter l

[Manishearth]

I would rather use @joshtriplett's heuristic here. mixed_script_confusables already uses this, we just need to reuse this: we lint on different strings that map to each other via mixed-script-confusables only.

[pickfire]

@Manishearth Ah, you are talking about the e1 and el. But isn't that up to the font used by the developer, should we even limit that?

By the way, how did you type rén?

[Manishearth]

@pickfire sigh the point is that the current patch catches that case incorrectly because it contains a non-confusable non-ascii character as well.

I have a compose key on my keyboard. I also have a chinese input method set up, but I wanted to specifically list out the word there.

[pickfire]

Is this link correct? Why do I get 404?

[Manishearth]

the tool is down right now, unicode is having IT issues

[pyfisch]

I don't think this is considered anymore.