Basic support for type: ignore comments

[MichaReiser]

Summary

This PR adds initial support for type: ignore. It doesn't do anything fancy yet like:

• Detecting invalid type ignore comments
• Detecting type ignore comments that are part of another suppression comment: # fmt: skip # type: ignore
• Suppressing specific lints type: ignore [code]
• Detecting unsused type ignore comments
• ...

The goal is to add this functionality in separate PRs.

Test Plan

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

Whoops. I accidentally commited this file when I rebased https://github.com/astral-sh/ruff/pull/14956/files#diff-b1807b646317ac1945d748f7db40451ac62c582b1bbc049b174e8d98f13d3f22 Probably because it didn't get stashed with git stash. So consider all code in this file as new

[carljm]

Nice!

[AlexWaygood]

Very nice!

[MichaReiser]

I adjusted the implementation to accept type: ignore comments on the start and end lines of the diagnostic range. I understand that this matches mypy's behavior #15046 (comment).

However, this in itself won't be sufficient for mypy compatibility. We'd also have to match mypy's diagnostic range which we currently don't for invalid assignments (#15046 (comment)). But that's a problem out of this PR's scope

[carljm]

Looks good, thank you for digging into the multi-line behavior here!

[carljm]

Could we use / 0 here and then the test would function without a TODO?

Or maybe that muddies the comparison with pyright, which doesn't error on division by zero

[MichaReiser]

It doesn't work with / 0 because Red Knot doesn't support cast yet (and without the cast it's Unknown / 0 which we seem to accept)

[MichaReiser]

Something for tomorrow. I want to take another look why we need to test both the start and the end. Ruff only tests the start. Testing both might be a problem for a future linter if we have

if True:
	print("test")
else: 
	pass  # knot: ignore

because the ignore on the pass would now ignore any error that applies to the entire else-clause.

[MichaReiser]

Not supporting end positions does seem unintuitive. For example, the following wouldn't work

y = (
    4 /
    0  # type: ignore
)

We should push users towards using specific error codes to mitigate the issue that I pointed out in #15046 (comment)

[carljm]

We should push users towards using specific error codes

And try to avoid overly-large diagnostic ranges. In particular, I suspect we should try to avoid diagnostic ranges on statements, because I think those are the cases where the end is least intuitive.