-
Notifications
You must be signed in to change notification settings - Fork 275
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
Allow extra option locations in source info when building an image #2803
Conversation
cc @gilwong00 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you run buf build -o tmp.bin on a sufficiently large repo before/after to see how big the diff is in size?
@bufdev, here's
That's about 4% difference. I'm happy to run this on any other repos, if you can think of other good examples I should try. |
This is fine. Make sure this is merged into |
@mfridman suggested
So 1.5% growth, 1.1%, and 4.1% respectively. Interestingly, the slimmed-down googleapis actually had the biggest delta. Average of 1.2% increase. |
Aye, aye! |
…2803) This opts into a feature in protocompile to produce more source code locations (for span and comment info) than protoc produces. This allows us to potentially report lint warnings with more precise position information, and it should also allows us to carry more comment information about custom option values into generated docs.
This is a feature I added to
protocompile
last year because it was easy to do because of the way thatprotocompile
parses the option values.(It can't easily be done in
protoc
because it doesn't actually parse message literals: it scans through the source to the end of the value, looking for a matching{
that closes the opening}
, and just stores the tokens in a string value. Later, the value is interpreted by using the Protobuf text format to unmarshal that string of tokens into a message.)Apparently, I forgot to enable it in
buf
last year. I did this specifically for things like linting custom options (like the protovalidate options), and we can see it pays off a bit in the updated test.The motivation for me remembering to add this today, so many months later, is so that we can capture more of the comments when rendering custom options in generated docs.