Include Bzlmod globals in builtin.proto
#18
Conversation
This allows consumers of the proto to learn about globals only available in `MODULE.bazel` under a new `ApiContext`. Also adds a smoke test to verify that common symbols are contained in the proto for each API context.
|
FYI @withered-magic @meteorcloudy Not sure who to assign for this part of the codebase, feel free to reassign. |
|
Parameters are now available. |
|
I pushed a new commit to add |
|
@tetromino are you the right person to review this? It's not too complicated and looks fine to me. |
|
@tetromino Friendly ping |
|
@tetromino Gentle ping, following up on bazelbuild#21936 (comment) |
|
@tetromino Friendly ping |
|
Warning Rate limit exceeded@arvi18 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 10 minutes and 1 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (6)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
Hi @tetromino, Thanks for sharing your thoughts as well as an alternative design earlier this year, and for capturing our feedback on additional requirements for the LSP use cases in bazelbuild#21979 🙂 I still agree with the overall design: aligning the generation of documentation pages and language servers to both rely on Stardoc protos is a very good solution. This makes sure that the published documentation and the in-editor suggestions from the LSP will stay in sync. I wonder if you can share additional details on your envisioned design, timeline, roadmap by now? Maybe the opensource community could contribute somehow, if we know what you are working towards and which design and work items you are having in mind? As one of the maintainers of the Bazel VSCode extension, I want to integrate a language server directly into the VSCode extension, such that all users can benefit from auto-completion, signature help etc. However, with the current state of both language servers (bazel-lsp by @cameron-martin and starpls by @withered-magic), I don't feel comfortable shipping them to a larger user base. We would immediately get bug reports that autocompletion only works unreliably or even not at all for bzlmod files. As such, I need your help to make this happen 🙂 I guess that Google has its own, internal language server for Starlark / Bazel and hence I understand that this is not your highest priority. If you could share your roadmap, envisioned design etc. we, the community, could maybe fill in the blanks to pave the path towards a widely available Bazel language server. Alternatively (e.g., in case the stardoc project is not getting sufficient funding inside Google for whatever reason), I would appreciate if we could reconsider merging this pull request as well as bazelbuild#21135, at least as a stop gap solution until we can work towards the long-term stardoc-based solution |
Sure. Step zero was a series of refactorings and cleanups around Step one was adding a way to represent the syntactic role of function params (fixed by bd1c3af) so that a documentation renderer can output Steps two and three will be to represent 2 additional bits of data in
I hope get this done in early July. |
|
Thanks for the update and the rough timeline! Are the remaining steps 2 and 3 all that's left to be done? Afaik, there is currently no way to dump Bazel's builtin functions, yet. From the Stardoc documentation, my understanding is that it is only possible to run stardoc on Starlark files? But Bazel's builtins are not all migrated to Starlark, and some of them probably never will. Is there still some additional command (e.g., |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hello @arvi18, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
Summary of Changes
This pull request focuses on enhancing the builtin.proto to include Bzlmod globals, specifically those available in MODULE.bazel files. This is achieved by adding a new ApiContext called MODULE. Additionally, the PR incorporates ApiContext.BZL globals for repository rule and module extension definitions. A new smoke test is introduced to verify that common symbols are present in the proto for each API context. This work is related to addressing issue bazel-contrib/vscode-bazel#1.
Highlights
- ApiContext Enhancement: A new
ApiContext.MODULEis added tobuiltin.prototo represent globals available inMODULE.bazelfiles. This is reflected insrc/main/protobuf/builtin.protoby addingMODULE = 3;to theApiContextenum. - Bzlmod Globals Inclusion: The changes in
src/main/java/com/google/devtools/build/docgen/ApiExporter.javaandsrc/main/java/com/google/devtools/build/docgen/SymbolFamilies.javaensure that globals specific toMODULE.bazelfiles are included when generating thebuiltin.proto. This involves adding a call toappendGlobalswithApiContext.MODULEand collecting module file globals. - Smoke Test Implementation: A new smoke test,
BuiltinProtoSmokeTest.java, is added to verify the presence of common symbols in the generatedbuiltin.protofor different API contexts. This test ensures that essential symbols likebazel_depare correctly documented under theMODULEcontext. - Dependency Injection: The
BUILDfile insrc/main/java/com/google/devtools/build/docgen/BUILDis updated to include//src/main/java/com/google/devtools/build/lib/bazel/bzlmod:resolutionas a runtime dependency for theApiExporter.
Changelog
Click here to see the changelog
- src/main/java/com/google/devtools/build/docgen/ApiExporter.java
- Added logic to append globals specifically for the
MODULEApiContext. - Modified to include module file globals when writing builtins.
- Added logic to append globals specifically for the
- src/main/java/com/google/devtools/build/docgen/BUILD
- Added
//src/main/java/com/google/devtools/build/lib/bazel/bzlmod:resolutionas a runtime dependency.
- Added
- src/main/java/com/google/devtools/build/docgen/SymbolFamilies.java
- Added
FakeRepositoryModuleimport. - Added
moduleFileGlobalsfield to store globals available inMODULE.bazelfiles. - Modified constructor to collect module file globals.
- Added getter method for
moduleFileGlobals. - Modified
collectBzlGlobalsto add methods fromFakeRepositoryModule. - Added
collectModuleFileGlobalsmethod to collect globals specifically forMODULE.bazelfiles.
- Added
- src/main/protobuf/builtin.proto
- Added
MODULEenum value to theApiContextenum.
- Added
- src/test/java/com/google/devtools/build/lib/BUILD
- Added
BuiltinProtoSmokeTestjava test target.
- Added
- src/test/java/com/google/devtools/build/lib/BuiltinProtoSmokeTest.java
- Created a new smoke test to verify the presence of common symbols in the generated
builtin.protofor different API contexts.
- Created a new smoke test to verify the presence of common symbols in the generated
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
In Bzlmod's realm, a module's call,
Globals defined, embracing all.
From proto's core,
New contexts soar,
Bazel's extension, standing tall.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
|
Warning Gemini encountered an error creating the review. You can try again by commenting |
This allows consumers of the proto to learn about globals only available in
MODULE.bazelunder a newApiContextMODULE.Also adds the
ApiContext.BZLglobals for repository rule and module extension definition.A new smoke test verifies that common symbols are contained in the proto for each API context.
Work towards bazel-contrib/vscode-bazel#1