[red-knot] Diagnostics attached to wrong file

[sharkdp]

There are cases where we add diagnostics with a source range from file A to the TypeCheckDiagnosticsBuilder of file B. A small example to trigger this bug is the following:

# test.py
from subprocess import Popen

We currently emit a (false positive?) invalid-base diagnostic here, probably because we don't understand the definition of Popen:

ruff/crates/red_knot_vendored/vendor/typeshed/stdlib/subprocess.pyi

Line 1845 in 924741c

class Popen(Generic[AnyStr]):

But the actual problem here is that we attach the diagnostic to test.py, not to typeshed/stdlib/subprocess.pyi (notice the large column offset, resulting from trying to translate the byte offset into line/col on the wrong file):

error[invalid-base] /home/shark/playground/test.py:3:61460 Invalid class base with type `object` (all bases must be a class, `Any`, `Unknown` or `Todo`)

I noticed this, because things can go wrong bad if the byte offset from file A does not translate to a valid-UTF-8 offset in file B. Or if there are out-of-bounds accesses (which are for some reason also only triggered with non-ASCII characters):

# Ä
from subprocess import Popen

thread 'main' panicked at crates/ruff_source_file/src/line_index.rs:117:28:
byte index 61498 is out of bounds of `# ä
from subprocess import Popen
`

What needs to be done here?

• Add an assertion to TypeCheckDiagnosticsBuilder that makes sure we never attach diagnostics for nodes from a different file?
• Prevent raising diagnostics from different files in the first place?