make const a toplevel expr or error

[vtjnash]

const can cause serious, subtle bugs when combined with precompilation. it is valid to use from the :toplevel scope, but it can cause problems if used at runtime (and it's already ignored when specified at the local scope. this could be fixed by warning for and ignoring the const declaration outside of the toplevel scope. or this could be fixed by internally distinguishing between const (as it is currently defined) and a new assigned once attribute (that provides none of the inference speed benefits of const, but just doesn't allow reassignment).

the following is fine:

module Fine
const binding = value
end

the following can confuse precompilation (and isn't great for type inference either):

module Bad
__init__() = (global const binding = value)
end

the following currently is ignored by parsing, so is neither bad nor good:

module Either
f() = (const localb = localv)
end

[yuyichao]

the following can confuse precompilation (and isn't great for type inference either):

module Bad
__init__() = (global const binding = value)
end

I think this is still really useful for some packages that load shared libraries.

[yuyichao]

IIRC, the plan in #11456 (or a related one) is that the compiler should look inside the function and see if there's a global const defined inside and reserve a slot for it. (Looking for the specific comment now)

Edit: Comment about this is here #11456 (comment)

[vtjnash]

#11456 is about making global variable bindings resolved early, this thread is about disallowing the addition of new global const bindings. #11456 (comment) is exactly the subtle but serious issue that can happen if global const is allowed (since ccall will precompile a call to a static pointer, rather than a runtime lookup)

[timholy]

Interesting. What if we define an __init_pre__() and __init_post__(), and require that any global const assignments happen in post? Would that solve the problem?

EDIT: init_post runs after loading the cache. init_pre runs before caching.

[yuyichao]

(since ccall will precompile a call to a static pointer, rather than a runtime lookup)

Is this an issue if the pointer is used in the same module and __init__ (or __init_post__) is not run when the module is pre-compiled?

[vtjnash]

@timholy that's just:

module MyModule
__init_pre__() = "here1"
__init_post__() = "there2"

__init__() = __init_post__()
__init_pre__()
end

@yuyichao less so, but only because we don't run __init__ before precompiling the module, so it becomes actually just becomes undefined behavior at runtime due to invalidating type inference.

[yuyichao]

so it becomes actually just becomes undefined behavior at runtime due to invalidating type inference.

Sorry I forgot to mention that this should also be combined with letting typeinf/precompile look into functions (especially __init__) to see that the const global will be assigned at runtime.

[timholy]

I think I get it now. Presumably "only" affects functions that get JITted before the cache is written?

[timholy]

From an inference perspective, I'm guessing that much of the benefit of what we now use global const ... for would be obtained if we had an of_const_type declaration.

[vtjnash]

Sorry I forgot to mention that this should also be combined with letting typeinf/precompile look into functions (especially init) to see that the const global will be assigned at runtime.

@carnaval is that something typeinference could handle?

I think I get it now. Presumably "only" affects functions that get JITted before the cache is written?

JIT isn't really the right term, since this is AOT compiling. But since this is AOT, it's generally beneficial to do as much work as possible to build a good / complete cache.

[vtjnash]

for would be obtained if we had an of_const_type declaration...

module OfConstType
const binding = Ref{T}()

binding[] = 1
Base.Test.@test binding[] === 1
end

[timholy]

Sorry, I don't understand your example.

[yuyichao]

module OfConstType
const binding = Ref{T}()

binding[] = 1
Base.Test.@test binding[] === 1
end

I guess I wouldn't mind only allowing real const in global scope if we can making var::Type (edit: as global variable) a syntax sugar for this.

[vtjnash]

that seems to be Jeff's plan #11456 (comment)