The ints in the path should be the field numbers and array indices along
the way from a top level field descriptor proto, like this:
Path: [4, 0, 2, 0]
Starting with the FileDescriptorProto:
4 -> FileDescriptorProto {
...
* repeated DescriptorProto message_type = 4;*
repeated EnumDescriptorProto enum_type = 5;
}
0 -> index into FileDescriptorProto.messages[0]
2 -> DescriptorProto {
optional name = 1;
* repeated FieldDescriptorProto field = 2;*
...
}
0 -> index into DescriptorProto.field[0]
Thus this path/Location [4, 0, 2, 0] applies to the whole field statement.
I believe the index of a message in the message_type array generally
corresponds to the order of all top-level message items in the file.
I also believe that the index of a field likewise corresponds to the
ordering of fields within the message.
So if you have to deal with nested messages, the path will start with:
[4, (top-level-message-index), 3, (index-of-nested-message-type), ...]
If I remember correctly, this breaks down for options because sometimes the
comments/location for an option is dropped, and when it is present the path
points to field 999 the uninterpreted options.
But maybe you already had gotten that far and I misunderstood your question.
On Fri, Sep 9, 2022 at 2:15 PM Kyle Papili <[email protected]> wrote:
> Is there somewhere in the documentation that provides clear table
> describing which numbers in the path correlate to which types? I have found
> some inconsistencies with what I had thought. Any link to a table like this?
>
> On Friday, September 9, 2022 at 4:14:46 PM UTC-4 [email protected] wrote:
>
>> Ah, no, there is no magic. I only meant that if you wanted to have one
>> part of your code match up location data to descriptor object and attach
>> the location info directly, you could do it in a custom option. There's no
>> getting around the actual awkward stepping through the paths to match them
>> up.
>>
>> On Fri, Sep 9, 2022 at 2:08 PM Kyle Papili <[email protected]> wrote:
>>
>>> Yes, the "hacky method" proposed by shaod@ is basically what I am doing
>>> currently. It just seems to be unnecessarily complicated.
>>>
>>> What do you mean "store the location object in a custom option extension
>>> on the object in question". How would I store the location object as a
>>> custom extension of the object without knowing the object? If I knew the
>>> object that that location corresponded to then my problem would be
>>> resolved. The only way to match up location objects to Proto objects from
>>> what I've found is the hacky path traversal suggested by Shaod@. Am I
>>> missing something here?
>>>
>>> On Friday, September 9, 2022 at 4:02:05 PM UTC-4 [email protected] wrote:
>>>
>>>> Unfortunately, the only way to know the path to the Location object is
>>>> to know the path to the descriptor proto object in question.
>>>> Alternatively, you could iterate through all the sourcecodeinfo
>>>> elements and use their paths to navigate to the correct descriptor object.
>>>> One technique I have used in the past is to iterate through all the
>>>> sourcecodeinfo elements and store the location object in a custom option
>>>> extension on the object in question (or the parent object if it something
>>>> that doesn't have options).
>>>>
>>>> Also, as shaod@ points out, some comments will not show up in
>>>> sourcecodeinfo.
>>>>
>>>> On Wednesday, September 7, 2022 at 4:11:32 PM UTC-6 [email protected]
>>>> wrote:
>>>>
>>>>> First keep in mind that some comments are detached and thus ignored by
>>>>> SourceCodeInfo.
>>>>>
>>>>> That being said, IIRC I've seen a very hacky way to achieve similar
>>>>> goals:
>>>>> https://github.com/protocolbuffers/protobuf/blob/3322c0b92a5001ade92608d75891d63c749d624d/src/google/protobuf/compiler/parser_unittest.cc#L2472
>>>>> On Thursday, September 1, 2022 at 7:16:52 AM UTC-7 [email protected]
>>>>> wrote:
>>>>>
>>>>>> I'm parsing a large number of protobuf files and am using the Source
>>>>>> Code Info descriptor to extract comment data from the source files as
>>>>>> well.
>>>>>> I currently use the FileDescriptorProto.ListFields() method to extract
>>>>>> the
>>>>>> DescriptorProto objects I care about as well as the SourceCodeInfo.
>>>>>>
>>>>>> To my knowledge, the only way to pair up Location fields with the
>>>>>> corresponding objects is via the path attribute
>>>>>> <https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.descriptor.pb>.
>>>>>> This is fine; except for the fact that involves me manually stepping
>>>>>> through said path to land at my parsed Protobuf Object. This gets
>>>>>> complicated when dealing with layers of nested_types and I am convinced
>>>>>> there must be a way for me to extract the path from the particular
>>>>>> DescriptorProto Object and then use that to match up the object with the
>>>>>> path specified in the corresponding Location field.
>>>>>>
>>>>>> In short: How can I easily pair up DescriptorProto objects with the
>>>>>> Location objects that correspond to them? Specifically for comment
>>>>>> parsing
>>>>>> purposes.
>>>>>>
>>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Protocol Buffers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/protobuf/0c8d36db-53f9-4179-942f-201cd205b9dfn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/protobuf/0c8d36db-53f9-4179-942f-201cd205b9dfn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> --
>> Jerry Berg | Software Engineer | [email protected] | 720-808-1188
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/protobuf/e97868df-f57d-45bf-b4f5-eeb0e2f4eed3n%40googlegroups.com
> <https://groups.google.com/d/msgid/protobuf/e97868df-f57d-45bf-b4f5-eeb0e2f4eed3n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
Jerry Berg | Software Engineer | [email protected] | 720-808-1188
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/protobuf/CAHLB6RfTsr1vDn23k_%3DcmOOvFjZ1DeKOaBA4gPamYpWuctqiAQ%40mail.gmail.com.
