Lines Matching refs:synthetic

53 placed into a one-field `oneof`. We call this a "synthetic" oneof, as it was not
60 proto3 presence. This is the major benefit of synthetic oneofs.
65 APIs. It is never safe to drop synthetic oneofs from a proto schema. Code
66 generators can (and should) skip synthetic oneofs when generating a user-facing
68 consumed programmatically, it is important to keep the synthetic oneofs around.
72 synthetic oneofs in code generators.
91   // We call _foo a "synthetic" oneof, since it was not created by the user.
101 2. Avoid generating any oneof-based accessors for the synthetic oneof. Its only
103    not aware of proto3 presence. The synthetic oneof should not appear anywhere
164 synthetic oneof) and users could start depending on these. That would create
211 synthetic oneofs.
273   // real_containing_oneof() returns nullptr for synthetic oneofs.
296   // total number of oneofs, excluding synthetic oneofs.
332    synthetic oneofs.  In particular:
333    - `OneofDescriptor::is_synthetic()`: returns true if this is a synthetic
336      but returns `nullptr` if the oneof is synthetic.
342 Proto3 `optional` fields and synthetic oneofs must work correctly when
345 1. Reflection for synthetic oneofs should work properly. Even though synthetic
352    proto3 `optional` field. It should not be fooled by the synthetic oneof into
356 synthetic oneofs, any code that *uses* your reflection interface should work
357 properly with no changes. This is the benefit of using synthetic oneofs.
372 you must verify that all synthetic oneofs are ordered after all "real" oneofs.