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

Split ModuleThreadContext off from ModuleFileGlobals #21749

Closed
wants to merge 1 commit into from

Conversation

Wyverald
Copy link
Member

ModuleFileGlobals used to serve as both the definition of Starlark methods available in MODULE.bazel files, and the state tracker for a module being built. This commit brings it more in line with other Starlark evaluation contexts where there's a simple object that just holds methods, and the actual state is stored in the StarlarkThread. ModuleThreadContext is that state object.

This commit is a pure mechanical refactor with no behavioral changes. It paves the way for us to allow root module MODULE.bazel files to import other files.

Work towards #17880.

ModuleFileGlobals used to serve as both the definition of Starlark methods available in MODULE.bazel files, *and* the state tracker for a module being built. This commit brings it more in line with other Starlark evaluation contexts where there's a simple object that just holds methods, and the actual state is stored in the StarlarkThread. ModuleThreadContext is that state object.

This commit is a pure mechanical refactor with no behavioral changes. It paves the way for us to allow root module MODULE.bazel files to import other files.

Work towards #17880.
@Wyverald Wyverald requested a review from brandjon March 20, 2024 21:13
@Wyverald Wyverald requested review from a team and meteorcloudy as code owners March 20, 2024 21:13
@Wyverald Wyverald requested review from katre and removed request for a team and katre March 20, 2024 21:13
@github-actions github-actions bot added team-Configurability platforms, toolchains, cquery, select(), config transitions team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. awaiting-review PR is awaiting review from an assigned reviewer labels Mar 20, 2024
@Wyverald
Copy link
Member Author

@zhengwei143 this PR includes a very small usage of record, which seems to be causing some failure on Windows arm64 only (could not locate class file for java.lang.Record). Any ideas?

@Wyverald Wyverald removed the team-Configurability platforms, toolchains, cquery, select(), config transitions label Mar 20, 2024
@fmeum
Copy link
Collaborator

fmeum commented Mar 20, 2024

@Wyverald Pretty sure this is the same issue as in #21702 (comment)

@meteorcloudy
Copy link
Member

meteorcloudy commented Mar 21, 2024

https://github.com/bazelbuild/rules_java/releases/tag/7.5.0 has been released, we can just upgrade rules_java for Bazel. /cc @hvadehra

@hvadehra
Copy link
Member

https://github.com/bazelbuild/rules_java/releases/tag/7.5.0 has been released, we can just upgrade rules_java for Bazel. /cc @hvadehra

#21729

@github-actions github-actions bot removed the awaiting-review PR is awaiting review from an assigned reviewer label Mar 26, 2024
bazel-io pushed a commit to bazel-io/bazel that referenced this pull request Apr 25, 2024
ModuleFileGlobals used to serve as both the definition of Starlark methods available in MODULE.bazel files, *and* the state tracker for a module being built. This commit brings it more in line with other Starlark evaluation contexts where there's a simple object that just holds methods, and the actual state is stored in the StarlarkThread. ModuleThreadContext is that state object.

This commit is a pure mechanical refactor with no behavioral changes. It paves the way for us to allow root module MODULE.bazel files to import other files.

Work towards bazelbuild#17880.

Closes bazelbuild#21749.

PiperOrigin-RevId: 619261497
Change-Id: Ibff3a311e1788f7d8089ca194933cfb5fcc53ee0
github-merge-queue bot pushed a commit that referenced this pull request Apr 25, 2024
ModuleFileGlobals used to serve as both the definition of Starlark
methods available in MODULE.bazel files, *and* the state tracker for a
module being built. This commit brings it more in line with other
Starlark evaluation contexts where there's a simple object that just
holds methods, and the actual state is stored in the StarlarkThread.
ModuleThreadContext is that state object.

This commit is a pure mechanical refactor with no behavioral changes. It
paves the way for us to allow root module MODULE.bazel files to import
other files.

Work towards #17880.

Closes #21749.

PiperOrigin-RevId: 619261497
Change-Id: Ibff3a311e1788f7d8089ca194933cfb5fcc53ee0

Commit
9facaaa

Co-authored-by: Xdng Yng <wyverald@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants