Allow extra option locations in source info when building an image#2803
Allow extra option locations in source info when building an image#2803
Conversation
|
cc @gilwong00 |
bufdev
left a comment
There was a problem hiding this comment.
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
protocompilelast year because it was easy to do because of the way thatprotocompileparses the option values.(It can't easily be done in
protocbecause 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
buflast 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.