Document unsupported rules

[LordAro]

One of the bits of feedback I've had from colleagues about using ruff is the lack of visibility over which rules are implemented and which aren't:

No I wouldn't have expected it, but one of my concerns about Ruff was potentially poor pycodestyle support, which is the main thing we wanted out of flake8. I've set up an example in Ruff's playground and it doesn't catch any issues, which from further inspection its pycodestyle support doesn't claim it supports these rules at all. I'd have assumed the table would be complete with gaps for no support instead of just missing rows for no support 😠
It looks from diffing with pycodestyle's rules that Ruff is missing E121-E133, of which only 4/11 rules are disabled by default in pycodestyle. I didn't actually know that pycodestyle disabled anything by default, and that would explain a lot of the changes that [snip] had to make when converting to Ruff. Ruff do have an issue for supporting the rest of the rules but it looks like it's not been thought about for a little while...

This is obviously specific to pycodestyle but it would apply to all linter types.

It'd be nice if the rules table listed everything unsupported or not. Would cover both "not yet supported" (like those mentioned above) and "never supported" (e.g. B001)

ruff 0.7.0

[MichaReiser]

Thanks for sharing this feedback. I understand that it can be confusing that Ruff lists linter categories without supporting all linters from upstream.

Our long-term solution to this is to re-categorize our rules (see #1774) to clarify that Ruff is not an exact reimplementation of upstream linters. We could then provide a migration tool that migrates your existing linter configuration and warns you about unsupported lint codes.

I don't know what a good short-term solution looks like. Adding all rules, including the unsupported rules (some of which we intentionally do not support), would bloat Ruff's documentation a lot. That's why I'm unsure if it is the right solution to communicate missing rules. We would also have to automate the documentation generation to ensure we remain up-to-date when upstream linters add new rules(we're trying to hit a moving target). Considering that this is possibly wasted work long term, it might be better to start with a migration tool right away.