protobuf

655 Commits

201 Branches

346 Tags

254 MiB

Tag: Branch: Tree: 04786dc2b3

Commit Graph

Author	SHA1	Message	Date
Josh Haberman	f8c26358f0	Changes for PR comments.	9 years ago
Josh Haberman	e9d79d2441	Added upb::FileDef, which represents the file defs are declared in. It is entirely optional: MessageDef/EnumDef can still exist on their own. But this can represent a def's file when it is desirable to do so (eg. for code generators). This approach will require that we change the way we handle extensions. But I think it will be a good change overall. Specifically, we previously handled extensions by duplicating the extended message and then adding the extension as a regular field to the duplicated message. This required also duplicating any messages that could reach the extended message. In the new world we will need a way of declaring and looking up extensions separately from the message being extended. This change also involves some notable changes to the generated code: - files are now called foo.upbdefs.h instead of foo.upb.h. This reflects the fact that we might possibly generate several different output files for a .proto file, and this one is just for defs. - we no longer generate selectors in the .h file. - the upbdefs.c no longer vends a SymbolTable. Now it vends the individual messages (and possibly a FileDef later). I think this will compose better once we can generate files where one generated files imports another. We also make the descriptor reader vend a list of FileDefs now. This is the best conceptual match for parsing a FileDescriptorSet.	9 years ago
Josh Haberman	c3e9a57a6f	Fixed some bad bugs in upb_env. Also added a unit test for upb_encoder that demonstrates the bugs and the fix.	10 years ago

Author

SHA1

Message

Date

Josh Haberman

f8c26358f0

Changes for PR comments.

9 years ago

Josh Haberman

e9d79d2441

Added upb::FileDef, which represents the file defs are declared in.

It is entirely optional: MessageDef/EnumDef can still exist
on their own.  But this can represent a def's file when it is
desirable to do so (eg. for code generators).

This approach will require that we change the way we handle
extensions.  But I think it will be a good change overall.

Specifically, we previously handled extensions by duplicating
the extended message and then adding the extension as a regular
field to the duplicated message.  This required also duplicating
any messages that could reach the extended message.

In the new world we will need a way of declaring and looking up
extensions separately from the message being extended.

This change also involves some notable changes to the generated
code:

- files are now called foo.upbdefs.h instead of foo.upb.h.
  This reflects the fact that we might possibly generate several
  different output files for a .proto file, and this one is just
  for defs.

- we no longer generate selectors in the .h file.

- the upbdefs.c no longer vends a SymbolTable.  Now it vends the
  individual messages (and possibly a FileDef later).  I think this
  will compose better once we can generate files where one
  generated files imports another.

We also make the descriptor reader vend a list of FileDefs now.
This is the best conceptual match for parsing a FileDescriptorSet.

9 years ago

Josh Haberman

c3e9a57a6f

Fixed some bad bugs in upb_env.

Also added a unit test for upb_encoder that
demonstrates the bugs and the fix.

10 years ago

3 Commits (04786dc2b3c68c8449b19fa2d12bd929f9813155)