Package com.google.protobuf

## 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 Summary

All Methods Instance Methods Abstract Methods
`DescriptorProtos.SourceCodeInfo.Location` `getLocation​(int index)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`int` `getLocationCount()` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`java.util.List<DescriptorProtos.SourceCodeInfo.Location>` `getLocationList()` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`DescriptorProtos.SourceCodeInfo.LocationOrBuilder` `getLocationOrBuilder​(int index)` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`
`java.util.List<? extends DescriptorProtos.SourceCodeInfo.LocationOrBuilder>` `getLocationOrBuilderList()` `repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

### Methods inherited from interface com.google.protobuf.MessageLiteOrBuilder

`isInitialized`

### Methods inherited from interface com.google.protobuf.MessageOrBuilder

`findInitializationErrors, getAllFields, getDefaultInstanceForType, getDescriptorForType, getField, getInitializationErrorString, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof`

### Method Detail

#### getLocationList

    java.util.List<DescriptorProtos.SourceCodeInfo.Location> getLocationList()

`repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

     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 descendent.  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.

#### getLocation

    DescriptorProtos.SourceCodeInfo.Location getLocation​(int index)

`repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

     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 descendent.  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.

#### getLocationCount

    int getLocationCount()

`repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

     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 descendent.  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.

#### getLocationOrBuilderList

    java.util.List<? extends DescriptorProtos.SourceCodeInfo.LocationOrBuilder> getLocationOrBuilderList()

`repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

     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 descendent.  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.

#### getLocationOrBuilder

    DescriptorProtos.SourceCodeInfo.LocationOrBuilder getLocationOrBuilder​(int index)

`repeated .google.protobuf.SourceCodeInfo.Location location = 1;`

     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 descendent.  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.