WIP,RFC: flow-based scope in top-level expressions

[JeffBezanson]

For #28789

This determines the scope of a variable in a scope block at the top level based on how it is used: if it's always read first then global, if always written first then local.

Based on the proposal here: https://discourse.julialang.org/t/new-scope-solution/16707

See the tests for examples, as well a few cases where a disambiguating local declaration was needed. They seem unavoidable to me, but feel free to discuss.

To do:

• get all tests passing (I haven't run them all yet)
• add more tests
• docs
• transition strategy (e.g. deprecation warning, or use the old behavior in ambiguous cases)

[StefanKarpinski]

@tkf pointed out that according to the spec I had proposed, this case should require an annotation:

for i = 1:1
    t = 100
end

The proposed rule was:

• if the first use of x on every path is a read, then x is global
• if the first use of x on every path is a write and there’s a read somewhere, then x is local
• otherwise x must have an explicit local or global annotation

The "and there's a read somewhere" clause on the second point would require an annotation.

[chethega]

It appears that @goto is handled by failure:

julia> dead = true
true

julia> for i=1:1
       @goto foo
       @label foo
       @show dead
       end
ERROR: syntax: Scope of variable "#1#value" is ambiguous. Please explicitly declare it global or local.

If it were unduly complex to analyze arbitrary CFGs in the frontend, then this would be fine with me. However,

julia> for i=1:1
       @goto foo
       @label foo
       global dead
       dead = 2
       @show dead
       end
ERROR: syntax: Scope of variable "#17#value" is ambiguous. Please explicitly declare it global or local.

wants to either work correctly, or become Error: @goto not supported in global scope.

What is required for Rebugger.jl?

[JeffBezanson]

#17#value clearly shouldn't show up there, so I'll fix that. But yes, goto significantly complicates this and is difficult to handle well. Closures are also a bit of a problem but we might be able to get away with ignoring them. Of course macros are also somewhat of an issue, since they can introduce variable reads and writes that aren't apparent in the code.