Add Y062: Forbid duplicates in Literal[] slices

[tomasr8]

Previous discussion for context: #435 (comment)

Example:
Literal[True, True, False, False] - emits Y062 for both True and False.

This is how the new rule interacts with Y061:

• Literal[None], Literal[None, None], etc.. - Only Y061 is emitted and the suggestion is always just None (previously Literal[None, None] would suggest Literal[] | None)
• Combination of None and other duplicates e.g. Literal[None, True, True] - emits Y061, which suggests Literal[True, True] | None, and a separate Y062. The Y061 suggestion is not entirely correct though. In theory we could provide a better one (i.e. Literal[True] | None) but I'm not sure if we should, given that we emit a separate Y062 as well.. Thoughts?

[AlexWaygood]

This looks great; I really like the way you put it together :)

[tomasr8]

Wow that's a hell of a review 😮 Thanks for the taking the time to write it all up! I had hunch the py38 fails would have something to do with the AST changes but wasn't sure so that cleared that up :) I ended up removing the offending doctest (agreed that it's probably not worth to try to fix it) and applied your suggestion to suppress Y061 when we emit Y062.

[tomasr8]

From my side, this should be gtg ;)

[AlexWaygood]

Nearly there! Left a smattering of minor suggestions :D

[tomasr8]

Applied! The test cases are much better with an actual explanation

[AlexWaygood]

LGTM. Thanks! :D

[github-actions]

This change has no effect on typeshed. 🤖🎉

[AlexWaygood]

Minutes after merging, I realised that we give completely incomprehensible suggestions for something like this:

from typing import Literal

x: Literal[None] | Literal[None, True]

Output from linting this:

foo.pyi:3:4: Y030 Multiple Literal members in a union. Use a single Literal, e.g. "Literal[None, None, True]".
foo.pyi:3:12: Y061 None inside "Literal[]" expression. Replace with "None"
foo.pyi:3:28: Y061 None inside "Literal[]" expression. Replace with "Literal[True] | None"

I don't think it's a massive issue, though, as this is a real edge case. Definitely not worth fixing if it would mean significantly complicating our code

[tomasr8]

Oh damn why are there some many edge cases every time.. 😆 But yeah, as you say, this one seems very uncommon so I'd leave it as is. If it becomes an issue later, we can revisit this..