[red-knot] Recognize an assignment in a function/class scopes as a global-scope definition for purposes of * imports if the assigned symbol is declared global

[AlexWaygood]

Summary

Further work towards #14169. If something like this exists in a foo.py module:

def f():
    global a
    a: bool = True

and a bar.py module has this:

from foo import *

reveal_type(a)

then we will now recognize a as bound in bar.py. We don't yet reveal bool as the inferred type, but that depends on fixing #15385.

Test Plan

Assertions in existing mdtests are modified, and some new assertions are added

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

[MichaReiser]

I don't know how hot this code path is but we could consider using hashbrown's hash table to only compute the hash key once (for global_declarations_in_scope and exports). But that's probably a premature optimization :)

[AlexWaygood]

I'll leave this for now (following our in-person conversation) but happy to look into this later if it shows up in profiling etc.!

[carljm]

Sorry for not getting to clarity on this sooner, but I feel like we shouldn't support this. While this PR doesn't add a lot of complexity, fully supporting this pattern will, because it means that the types of symbols in an outer scope can depend on an arbitrary nested scope.

I think it is reasonable to require that if you use global in a function and assign to that name, the name must explicitly exist in the global scope.

If we do end up deciding we have to support this pattern, I want to add full support for it altogether (that is, not do star-import support for it separately from actual type inference support) so we can see the full picture of what it requires.

[AlexWaygood]

yes, after discussing this with you the other day, I agree that we probably shouldn't do this right now. Let's add support for global statements generally first, and see where we land on that. We can possibly revive this after we do that, but it doesn't seem like a priority in any event.