← Back to branch summary

~ubuntu-branches/ubuntu/trusty/protobuf/trusty-proposed

« back to all changes in this revision

Viewing changes to src/google/protobuf/descriptor.proto

  • Committer: Bazaar Package Importer
  • Author(s): Matthias Klose
  • Date: 2011-05-31 14:41:47 UTC
  • mfrom: (2.2.8 sid)
  • Revision ID: james.westby@ubuntu.com-20110531144147-s41g5fozgvyo462l
Tags: 2.4.0a-2ubuntu1
* Merge with Debian; remaining changes:
  - Fix linking with -lpthread.

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/google/protobuf/descriptor.proto
67
67
  repeated FieldDescriptorProto extension = 7;
68
68
 
69
69
  optional FileOptions options = 8;
 
70
 
 
71
  // This field contains optional information about the original source code.
 
72
  // You may safely remove this entire field whithout harming runtime
 
73
  // functionality of the descriptors -- the information is needed only by
 
74
  // development tools.
 
75
  optional SourceCodeInfo source_code_info = 9;
70
76
}
71
77
 
72
78
// Describes a message type.
245
251
  // top-level extensions defined in the file.
246
252
  optional bool java_multiple_files = 10 [default=false];
247
253
 
 
254
  // If set true, then the Java code generator will generate equals() and
 
255
  // hashCode() methods for all messages defined in the .proto file. This is
 
256
  // purely a speed optimization, as the AbstractMessage base class includes
 
257
  // reflection-based implementations of these methods.
 
258
  optional bool java_generate_equals_and_hash = 20 [default=false];
 
259
 
248
260
  // Generated classes can be optimized for speed or code size.
249
261
  enum OptimizeMode {
250
262
    SPEED = 1;        // Generate complete code for parsing, serialization,
264
276
  // early versions of proto2.
265
277
  //
266
278
  // Generic services are now considered deprecated in favor of using plugins
267
 
  // that generate code specific to your particular RPC system.  If you are
268
 
  // using such a plugin, set these to false.  In the future, we may change
269
 
  // the default to false, so if you explicitly want generic services, you
270
 
  // should explicitly set these to true.
271
 
  optional bool cc_generic_services = 16 [default=true];
272
 
  optional bool java_generic_services = 17 [default=true];
273
 
  optional bool py_generic_services = 18 [default=true];
 
279
  // that generate code specific to your particular RPC system.  Therefore,
 
280
  // these default to false.  Old code which depends on generic services should
 
281
  // explicitly set them to true.
 
282
  optional bool cc_generic_services = 16 [default=false];
 
283
  optional bool java_generic_services = 17 [default=false];
 
284
  optional bool py_generic_services = 18 [default=false];
274
285
 
275
286
  // The parser stores options it doesn't recognize here. See above.
276
287
  repeated UninterpretedOption uninterpreted_option = 999;
430
441
  optional int64 negative_int_value = 5;
431
442
  optional double double_value = 6;
432
443
  optional bytes string_value = 7;
 
444
  optional string aggregate_value = 8;
 
445
}
 
446
 
 
447
// ===================================================================
 
448
// Optional source code info
 
449
 
 
450
// Encapsulates information about the original source file from which a
 
451
// FileDescriptorProto was generated.
 
452
message SourceCodeInfo {
 
453
  // A Location identifies a piece of source code in a .proto file which
 
454
  // corresponds to a particular definition.  This information is intended
 
455
  // to be useful to IDEs, code indexers, documentation generators, and similar
 
456
  // tools.
 
457
  //
 
458
  // For example, say we have a file like:
 
459
  //   message Foo {
 
460
  //     optional string foo = 1;
 
461
  //   }
 
462
  // Let's look at just the field definition:
 
463
  //   optional string foo = 1;
 
464
  //   ^       ^^     ^^  ^  ^^^
 
465
  //   a       bc     de  f  ghi
 
466
  // We have the following locations:
 
467
  //   span   path               represents
 
468
  //   [a,i)  [ 4, 0, 2, 0 ]     The whole field definition.
 
469
  //   [a,b)  [ 4, 0, 2, 0, 4 ]  The label (optional).
 
470
  //   [c,d)  [ 4, 0, 2, 0, 5 ]  The type (string).
 
471
  //   [e,f)  [ 4, 0, 2, 0, 1 ]  The name (foo).
 
472
  //   [g,h)  [ 4, 0, 2, 0, 3 ]  The number (1).
 
473
  //
 
474
  // Notes:
 
475
  // - A location may refer to a repeated field itself (i.e. not to any
 
476
  //   particular index within it).  This is used whenever a set of elements are
 
477
  //   logically enclosed in a single code segment.  For example, an entire
 
478
  //   extend block (possibly containing multiple extension definitions) will
 
479
  //   have an outer location whose path refers to the "extensions" repeated
 
480
  //   field without an index.
 
481
  // - Multiple locations may have the same path.  This happens when a single
 
482
  //   logical declaration is spread out across multiple places.  The most
 
483
  //   obvious example is the "extend" block again -- there may be multiple
 
484
  //   extend blocks in the same scope, each of which will have the same path.
 
485
  // - A location's span is not always a subset of its parent's span.  For
 
486
  //   example, the "extendee" of an extension declaration appears at the
 
487
  //   beginning of the "extend" block and is shared by all extensions within
 
488
  //   the block.
 
489
  // - Just because a location's span is a subset of some other location's span
 
490
  //   does not mean that it is a descendent.  For example, a "group" defines
 
491
  //   both a type and a field in a single declaration.  Thus, the locations
 
492
  //   corresponding to the type and field and their components will overlap.
 
493
  // - Code which tries to interpret locations should probably be designed to
 
494
  //   ignore those that it doesn't understand, as more types of locations could
 
495
  //   be recorded in the future.
 
496
  repeated Location location = 1;
 
497
  message Location {
 
498
    // Identifies which part of the FileDescriptorProto was defined at this
 
499
    // location.
 
500
    //
 
501
    // Each element is a field number or an index.  They form a path from
 
502
    // the root FileDescriptorProto to the place where the definition.  For
 
503
    // example, this path:
 
504
    //   [ 4, 3, 2, 7, 1 ]
 
505
    // refers to:
 
506
    //   file.message_type(3)  // 4, 3
 
507
    //       .field(7)         // 2, 7
 
508
    //       .name()           // 1
 
509
    // This is because FileDescriptorProto.message_type has field number 4:
 
510
    //   repeated DescriptorProto message_type = 4;
 
511
    // and DescriptorProto.field has field number 2:
 
512
    //   repeated FieldDescriptorProto field = 2;
 
513
    // and FieldDescriptorProto.name has field number 1:
 
514
    //   optional string name = 1;
 
515
    //
 
516
    // Thus, the above path gives the location of a field name.  If we removed
 
517
    // the last element:
 
518
    //   [ 4, 3, 2, 7 ]
 
519
    // this path refers to the whole field declaration (from the beginning
 
520
    // of the label to the terminating semicolon).
 
521
    repeated int32 path = 1 [packed=true];
 
522
 
 
523
    // Always has exactly three or four elements: start line, start column,
 
524
    // end line (optional, otherwise assumed same as start line), end column.
 
525
    // These are packed into a single field for efficiency.  Note that line
 
526
    // and column numbers are zero-based -- typically you will want to add
 
527
    // 1 to each before displaying to a user.
 
528
    repeated int32 span = 2 [packed=true];
 
529
 
 
530
    // TODO(kenton):  Record comments appearing before and after the
 
531
    // declaration.
 
532
  }
433
533
}