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

lexgen 20241030 #785

Merged
merged 5 commits into from
Nov 5, 2024
Merged

lexgen 20241030 #785

merged 5 commits into from
Nov 5, 2024

Conversation

bnewbold
Copy link
Collaborator

@brianolson: there was a lexgen issue in here that I manually worked around. we have a new lexicon which uses a ref directly for the API endpoint "input" schema, which maybe hasn't be exercised before.

@brianolson
Copy link
Contributor

Is there a way to fix this so that the next person to run make lexgen doesn't undo that patch? e.g. I check this out and run make lexgen and ...

-func SetUpsertSet(ctx context.Context, c *xrpc.Client, input *SetDefs_Set) (*SetDefs_SetView, error) {
+func SetUpsertSet(ctx context.Context, c *xrpc.Client, input *SetUpsertSet_Input) (*SetDefs_SetView, error) {

@bnewbold
Copy link
Collaborator Author

bnewbold commented Nov 5, 2024

@brianolson I have a PR trying to fix lexgen for this here: #788

@bnewbold bnewbold merged commit 6ac14ce into main Nov 5, 2024
7 checks passed
@bnewbold bnewbold deleted the bnewbold/lexgen-20241030 branch November 5, 2024 01:08
bnewbold added a commit that referenced this pull request Nov 5, 2024
This tries to resolve the situation discovered in
#785, with the ozone
"upsertSet" procedure.

That lexicon specifies the input schema via reference, instead of an
"object" schema in-place.

This code could use real review, I just banged on it until it worked for
the current lexicon.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants