DescriptorProtos.SourceCodeInfoOrBuilder
Date: 2017-07-08

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

    Methods
    Modifier and Type | Method and Description
    --- | ---
    `DescriptorProtos.SourceCodeInfo.Location` | `getLocation(int index)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `int` | `getLocationCount()` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `java.util.List<DescriptorProtos.SourceCodeInfo.Location>` | `getLocationList()` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `DescriptorProtos.SourceCodeInfo.LocationOrBuilder` | `getLocationOrBuilder(int index)` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.
    `java.util.List<? extends DescriptorProtos.SourceCodeInfo.LocationOrBuilder>` | `getLocationOrBuilderList()` A Location identifies a piece of source code in a .proto file which corresponds to a particular definition.

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

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

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

      `isInitialized`

- - ### Method Detail

    - #### getLocationList

          java.util.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 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.

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

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

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

    - #### getLocationOrBuilderList

          java.util.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 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.

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

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