-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support type annotations on global variables #43671
Conversation
I think we will need to support this. Users would expect to write |
a633b01
to
c12180e
Compare
That seems like a quite weird feature to me. Was this implemented because it was easy or does it have some good use cases? |
We could disallow adding these type annotations inside local scopes, but since we already allow defining new globals from local scopes, I think it's only consistent to allow declaring new typed ones as well. This was a bit of a special case before my last commit, since lowering would then use that annotation to add the automatic conversion. Now, this automatic conversion is always added on assignments to globals though, so there's not really much special handling except that we explicitly tell lowering to always set binding types from the toplevel via the |
Very cool, great feature! Is this limited to literal types, or will it be possible to do |
Any valid top level expression is fine. I'm not sure we need such a |
/buildkite rerun failed |
new types should go at end of struct
This is an initial proposal for supporting typed globals based on #43455. The syntax for this is either `global x::T` or just doing `x::T = 1` in global scope. It is even supported to add these annotations to globals from inside functions. The type declaration will then be applied when the method is defined and inside the function body conversion to the specified type will happen automatically, similar to type annotations for local variables. This conversion will not be applied if the assignment is not done inside the same scope of the type annotation however. This could potentially be supported as well, but the problem is that this would mean any assignment to a global variable - typed or not - would need to go through a call to `convert` first, since lowering can't know if a given binding already has a type annotation. This probably wouldn't be a good thing for latency and sysimage size and would add an invalidation risk. It is allowed to refine a type annotation, but there will be a warning. Widening the type or changing it to any other type that is not a subtype of the previous one is an error, since that could cause cached compiled code to become invalid. replaces #43455 closes #964
Accidentally missed this in #43671
Accidentally missed this in #43671
add type declarations to global bindings replaces JuliaLang#43455 closes JuliaLang#964 Co-authored-by: Miguel Raz Guzmán Macedo <[email protected]>
Accidentally missed this in JuliaLang#43671
This got missed in #43671.
- it seems like `:ccall` preserves may now include `SlotNumber` objects, and so we need to update `build_compiled_call!` accordingly - JuliaLang/julia#43671 increased the number of statements of code that involves assignment to a global variable
This got missed in #43671.
- it seems like `:ccall` preserves may now include `SlotNumber` objects, and so we need to update `build_compiled_call!` accordingly - JuliaLang/julia#43671 increased the number of statements of code that involves assignment to a global variable
- it seems like `:ccall` preserves may now include `SlotNumber` objects, and so we need to update `build_compiled_call!` accordingly - JuliaLang/julia#43671 increased the number of statements of code that involves assignment to a global variable
add type declarations to global bindings replaces JuliaLang#43455 closes JuliaLang#964 Co-authored-by: Miguel Raz Guzmán Macedo <[email protected]>
Accidentally missed this in JuliaLang#43671
This got missed in JuliaLang#43671.
add type declarations to global bindings replaces JuliaLang#43455 closes JuliaLang#964 Co-authored-by: Miguel Raz Guzmán Macedo <[email protected]>
Accidentally missed this in JuliaLang#43671
This got missed in JuliaLang#43671.
…54379) The performance tip from #43671 by @simeonschaub > If a global is known to always be of the same type, [the type should be annotated](https://docs.julialang.org/en/v1/manual/variables-and-scoping/#man-typed-globals). was a bit unclear to me, because it does not apply to `const` globals (whose type requires no annotation). This PR clarifies that point
…uliaLang#54379) The performance tip from JuliaLang#43671 by @simeonschaub > If a global is known to always be of the same type, [the type should be annotated](https://docs.julialang.org/en/v1/manual/variables-and-scoping/#man-typed-globals). was a bit unclear to me, because it does not apply to `const` globals (whose type requires no annotation). This PR clarifies that point
This is an initial proposal for supporting typed globals based on #43455.
The syntax for this is either
global x::T
or just doingx::T = 1
inglobal scope. It is even supported to add these annotations to globals
from inside functions.
The type declaration will then be applied whenthe method is defined and inside the function body conversion to the
specified type will happen automatically, similar to type annotations
for local variables.
This conversion will not be applied if the assignment is not done insidethe same scope of the type annotation however. This could potentially be
supported as well, but the problem is that this would mean any
assignment to a global variable - typed or not - would need to go
through a call to
convert
first, since lowering can't know if a givenbinding already has a type annotation. This probably wouldn't be a good
thing for latency and sysimage size and would add an invalidation risk.
Any assignment to a global now adds a conversion step and a type
assertion, similar to how type annotations work inside local scopes.
It is allowed to refine a type annotation, but there will be a warning.
Widening the type or changing it to any other type that is not a subtype
of the previous one is an error, since that could cause cached compiled
code to become invalid.
replaces #43455
closes #964