Skip to content
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

uninitialized typed global can only be imported qualified and not directly #54954

Closed
schlichtanders opened this issue Jun 27, 2024 · 4 comments · Fixed by #54956
Closed

uninitialized typed global can only be imported qualified and not directly #54954

schlichtanders opened this issue Jun 27, 2024 · 4 comments · Fixed by #54956
Labels
bug Indicates an unexpected problem or unintended behavior

Comments

@schlichtanders
Copy link

Following up on this discourse thread I want to raise awareness to uninitialized typed global variables.

It is an awesome concept which I'd like to use for initializing secret config values at initial runtime (at the start of my main-method).

However unfortunately they can only be imported via qualified access. My case is that I want to import it from a submodule which fails.

  • I.e. importing the entire module like import TopLevelProject and accessing it with TopLevelProject.variable works.
  • but using TopLevelProject: variable gives the error ERROR: LoadError: UndefVarError: variable not defined, even if the variable is not actually used within top-level statements, but just inside functions.

It would be awesome if the variable an already be referenced, even though it is not yet initialized.

@nsajko nsajko added the feature Indicates new feature / enhancement requests label Jun 27, 2024
@nsajko
Copy link
Contributor

nsajko commented Jun 27, 2024

Can you give an example reproducer for your error message, and a minimal example of desired behavior?

@schlichtanders
Copy link
Author

here a short sketch

module MyPackage
using Configurations: @option
@option struct MyConfigType
    specialconfig::Bool = false
end
global CONFIG::MyConfigType

module SubModule
    using MyPackage: CONFIG

    function do_something_configurable()
        if CONFIG.specialconfig
             print("yeah")
        end
    end
end

function main()
    CONFIG = MyConfigType(specialconfig=true)
    SubModule.do_something_configurable()
end
end

and then call MyPackage.main()

@Keno
Copy link
Member

Keno commented Jun 27, 2024

I think this is just a bug that happened when this syntax got added. Will put up a PR.

@Keno Keno added bug Indicates an unexpected problem or unintended behavior and removed feature Indicates new feature / enhancement requests labels Jun 27, 2024
Keno added a commit that referenced this issue Jun 27, 2024
In `using A.B`, we need to evaluate `A.B` to add the module to the
using list. However, in `using A: B`, we do not care about the value
of `A.B`, we only operate at the binding level. These two operations
share a code path and the evaluation of `A.B` happens early and is
unused on the `using A: B` path. I believe this was an unintentional
oversight when the latter syntax was added. Fixes #54954.
@Keno
Copy link
Member

Keno commented Jun 27, 2024

#54956

@Keno Keno closed this as completed in 89e391b Jun 28, 2024
KristofferC pushed a commit that referenced this issue Jul 23, 2024
In `using A.B`, we need to evaluate `A.B` to add the module to the using
list. However, in `using A: B`, we do not care about the value of `A.B`,
we only operate at the binding level. These two operations share a code
path and the evaluation of `A.B` happens early and is unused on the
`using A: B` path. I believe this was an unintentional oversight when
the latter syntax was added. Fixes #54954.

(cherry picked from commit 89e391b)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants