lexgen: incorporate new tools.ozone namespace; bunch of old lexicons deprecated #617
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@bnewbold the pointer and string changes are manual fixes that we need for now while a cborgen bug gets worked out. Iirc this has to do with pointers to strings and there's only one spot in the generated code that causes this error. If you manually replace the |
ericvolp12
approved these changes
Mar 12, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
DO NOT MERGE YET
This is based off the atproto PR: bluesky-social/atproto#2288
Does mostly expected things, adding
api/ozonefor tools.ozone.* namespace. Easier than expected because no records in that namespace, so no cborgen needed.There are some cborgen changes rolled up in this PR. I think I didn't commit changes to at least the bsky codegen, something about string and pointer-to-string. I assume those are unrelated to the namespace stuff and should be resolved in a separate clean PR.
I haven't self-reviewed or tested this at all, should do that before merging or deploying. I think I caught all the string constants withcom.atproto.admin.defs#whateverin code, but there might be more lurking (these don't result in compile-time errors).