Interface DescriptorProtos.SourceCodeInfoOrBuilder

All Superinterfaces:
MessageLiteOrBuilder, MessageOrBuilder
All Known Implementing Classes:
DescriptorProtos.SourceCodeInfo, DescriptorProtos.SourceCodeInfo.Builder
Enclosing class:
DescriptorProtos
public static interface DescriptorProtos.SourceCodeInfoOrBuilder extends MessageOrBuilder

  • Method Details

    • getLocationList

      List<DescriptorProtos.SourceCodeInfo.Location> getLocationList()
      A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.  This information is intended
to be useful to IDEs, code indexers, documentation generators, and similar
tools.
For example, say we have a file like:
  message Foo {
    optional string foo = 1;
  }
Let's look at just the field definition:
  optional string foo = 1;
  ^       ^^     ^^  ^  ^^^
  a       bc     de  f  ghi
We have the following locations:
  span   path               represents
  [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
  [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
  [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
  [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
  [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
Notes:
- A location may refer to a repeated field itself (i.e. not to any
  particular index within it).  This is used whenever a set of elements are
  logically enclosed in a single code segment.  For example, an entire
  extend block (possibly containing multiple extension definitions) will
  have an outer location whose path refers to the "extensions" repeated
  field without an index.
- Multiple locations may have the same path.  This happens when a single
  logical declaration is spread out across multiple places.  The most
  obvious example is the "extend" block again -- there may be multiple
  extend blocks in the same scope, each of which will have the same path.
- A location's span is not always a subset of its parent's span.  For
  example, the "extendee" of an extension declaration appears at the
  beginning of the "extend" block and is shared by all extensions within
  the block.
- Just because a location's span is a subset of some other location's span
  does not mean that it is a descendant.  For example, a "group" defines
  both a type and a field in a single declaration.  Thus, the locations
  corresponding to the type and field and their components will overlap.
- Code which tries to interpret locations should probably be designed to
  ignore those that it doesn't understand, as more types of locations could
  be recorded in the future.
      repeated .google.protobuf.SourceCodeInfo.Location location = 1;

    • getLocation

      DescriptorProtos.SourceCodeInfo.Location getLocation(int index)
      A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.  This information is intended
to be useful to IDEs, code indexers, documentation generators, and similar
tools.
For example, say we have a file like:
  message Foo {
    optional string foo = 1;
  }
Let's look at just the field definition:
  optional string foo = 1;
  ^       ^^     ^^  ^  ^^^
  a       bc     de  f  ghi
We have the following locations:
  span   path               represents
  [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
  [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
  [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
  [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
  [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
Notes:
- A location may refer to a repeated field itself (i.e. not to any
  particular index within it).  This is used whenever a set of elements are
  logically enclosed in a single code segment.  For example, an entire
  extend block (possibly containing multiple extension definitions) will
  have an outer location whose path refers to the "extensions" repeated
  field without an index.
- Multiple locations may have the same path.  This happens when a single
  logical declaration is spread out across multiple places.  The most
  obvious example is the "extend" block again -- there may be multiple
  extend blocks in the same scope, each of which will have the same path.
- A location's span is not always a subset of its parent's span.  For
  example, the "extendee" of an extension declaration appears at the
  beginning of the "extend" block and is shared by all extensions within
  the block.
- Just because a location's span is a subset of some other location's span
  does not mean that it is a descendant.  For example, a "group" defines
  both a type and a field in a single declaration.  Thus, the locations
  corresponding to the type and field and their components will overlap.
- Code which tries to interpret locations should probably be designed to
  ignore those that it doesn't understand, as more types of locations could
  be recorded in the future.
      repeated .google.protobuf.SourceCodeInfo.Location location = 1;

    • getLocationCount

      int getLocationCount()
      A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.  This information is intended
to be useful to IDEs, code indexers, documentation generators, and similar
tools.
For example, say we have a file like:
  message Foo {
    optional string foo = 1;
  }
Let's look at just the field definition:
  optional string foo = 1;
  ^       ^^     ^^  ^  ^^^
  a       bc     de  f  ghi
We have the following locations:
  span   path               represents
  [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
  [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
  [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
  [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
  [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
Notes:
- A location may refer to a repeated field itself (i.e. not to any
  particular index within it).  This is used whenever a set of elements are
  logically enclosed in a single code segment.  For example, an entire
  extend block (possibly containing multiple extension definitions) will
  have an outer location whose path refers to the "extensions" repeated
  field without an index.
- Multiple locations may have the same path.  This happens when a single
  logical declaration is spread out across multiple places.  The most
  obvious example is the "extend" block again -- there may be multiple
  extend blocks in the same scope, each of which will have the same path.
- A location's span is not always a subset of its parent's span.  For
  example, the "extendee" of an extension declaration appears at the
  beginning of the "extend" block and is shared by all extensions within
  the block.
- Just because a location's span is a subset of some other location's span
  does not mean that it is a descendant.  For example, a "group" defines
  both a type and a field in a single declaration.  Thus, the locations
  corresponding to the type and field and their components will overlap.
- Code which tries to interpret locations should probably be designed to
  ignore those that it doesn't understand, as more types of locations could
  be recorded in the future.
      repeated .google.protobuf.SourceCodeInfo.Location location = 1;

    • getLocationOrBuilderList

      List<? extends DescriptorProtos.SourceCodeInfo.LocationOrBuilder> getLocationOrBuilderList()
      A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.  This information is intended
to be useful to IDEs, code indexers, documentation generators, and similar
tools.
For example, say we have a file like:
  message Foo {
    optional string foo = 1;
  }
Let's look at just the field definition:
  optional string foo = 1;
  ^       ^^     ^^  ^  ^^^
  a       bc     de  f  ghi
We have the following locations:
  span   path               represents
  [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
  [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
  [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
  [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
  [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
Notes:
- A location may refer to a repeated field itself (i.e. not to any
  particular index within it).  This is used whenever a set of elements are
  logically enclosed in a single code segment.  For example, an entire
  extend block (possibly containing multiple extension definitions) will
  have an outer location whose path refers to the "extensions" repeated
  field without an index.
- Multiple locations may have the same path.  This happens when a single
  logical declaration is spread out across multiple places.  The most
  obvious example is the "extend" block again -- there may be multiple
  extend blocks in the same scope, each of which will have the same path.
- A location's span is not always a subset of its parent's span.  For
  example, the "extendee" of an extension declaration appears at the
  beginning of the "extend" block and is shared by all extensions within
  the block.
- Just because a location's span is a subset of some other location's span
  does not mean that it is a descendant.  For example, a "group" defines
  both a type and a field in a single declaration.  Thus, the locations
  corresponding to the type and field and their components will overlap.
- Code which tries to interpret locations should probably be designed to
  ignore those that it doesn't understand, as more types of locations could
  be recorded in the future.
      repeated .google.protobuf.SourceCodeInfo.Location location = 1;

    • getLocationOrBuilder

      DescriptorProtos.SourceCodeInfo.LocationOrBuilder getLocationOrBuilder(int index)
      A Location identifies a piece of source code in a .proto file which
corresponds to a particular definition.  This information is intended
to be useful to IDEs, code indexers, documentation generators, and similar
tools.
For example, say we have a file like:
  message Foo {
    optional string foo = 1;
  }
Let's look at just the field definition:
  optional string foo = 1;
  ^       ^^     ^^  ^  ^^^
  a       bc     de  f  ghi
We have the following locations:
  span   path               represents
  [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
  [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
  [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
  [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
  [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
Notes:
- A location may refer to a repeated field itself (i.e. not to any
  particular index within it).  This is used whenever a set of elements are
  logically enclosed in a single code segment.  For example, an entire
  extend block (possibly containing multiple extension definitions) will
  have an outer location whose path refers to the "extensions" repeated
  field without an index.
- Multiple locations may have the same path.  This happens when a single
  logical declaration is spread out across multiple places.  The most
  obvious example is the "extend" block again -- there may be multiple
  extend blocks in the same scope, each of which will have the same path.
- A location's span is not always a subset of its parent's span.  For
  example, the "extendee" of an extension declaration appears at the
  beginning of the "extend" block and is shared by all extensions within
  the block.
- Just because a location's span is a subset of some other location's span
  does not mean that it is a descendant.  For example, a "group" defines
  both a type and a field in a single declaration.  Thus, the locations
  corresponding to the type and field and their components will overlap.
- Code which tries to interpret locations should probably be designed to
  ignore those that it doesn't understand, as more types of locations could
  be recorded in the future.
      repeated .google.protobuf.SourceCodeInfo.Location location = 1;