directives_type_checking.py: do not assert that type checkers must ignore all type errors in if not TYPE_CHECKING blocks

[AlexWaygood]

This test currently asserts that type checkers should not emit errors for clearly incorrect code in if not TYPE_CHECKING blocks. Maybe that's reasonable behaviour, and maybe it's not, but it's never been specified in any PEP and it's not currently mandated by the spec. If we want to enforce that type checkers have to have this behaviour, then I think it should go via the normal process for modifications to the spec. In the meantime, I don't think it should be something asserted by the conformance suite.

This PR changes directives_type_checking.py so that it still asserts that type checkers should understand the TYPE_CHECKING constant as always-true, but so that it no longer asserts that type checkers should silence all diagnostics in these code regions, which goes far beyond what the spec mandates.

[JelleZijlstra]

It's true that the spec doesn't say anything here, but I do feel that ty is in the wrong for emitting errors within if not TYPE_CHECKING. In my view, the point of doing if not TYPE_CHECKING is to do crazy runtime things that the type checker may not understand.

[AlexWaygood]

In my view, the point of doing if not TYPE_CHECKING is to do crazy runtime things that the type checker may not understand.

I agree that that's one of the things it's often used for. And for this very reason, we deliberately suppress many errors in unreachable regions that we would normally emit in regions we infer as being reachable. We just don't suppress literally all errors in these regions — but that's what the test here currently mandates.

[rchen152]

Hmm. I agree with Jelle that I don't think type checkers should emit errors in if not TYPE_CHECKING blocks. It's true that the spec doesn't say anything about it, so I wouldn't object too strenuously to this being taken out of the conformance tests, but it seems like it might be better to change the spec.