| Commit message (Collapse) | Author | Age |
|
|
| |
Add unknown field support for csharp
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If messages A and B have the same oneof case, which is a message
type, and we merge B into A, those sub-messages should be merged.
Fixes #3200.
Note that I haven't regenerated all the code, as some of the protos
have been changed, breaking generation.
|
|
|
|
|
| |
This addressbook.proto now belongs to its own bazel pacakge and can't be
accessed in bazel protobuf_test target.
|
|\ |
|
| |
| |
| | |
* Remove using std::{set,map}
|
| | |
|
|/
|
|
|
|
|
|
| |
This prevents the contents of the std namespace from being effectively
pulled into the top-level namespace in all translation units that
include common.h. I left in individual using statements for a few common
things like std::set and std::map, because it did not seem worth going
through the churn of updating the whole codebase to fix those right now.
|
|
|
|
| |
conformance.proto
|
| |
|
|
|
|
| |
PreferredAlias into OriginalNameAttribute to remove the duplication (#2727)
|
|
|
|
|
|
|
|
|
|
|
|
| |
This consists of:
- Changing the codegen for the fixed set of options protos, to parse unknown fields instead of skipping them
- Add a new CustomOptions type in the C# support library
- Expose CustomOptions properties from the immutable proto wrappers in the support library
Only single-value options are currently supported, and fetching options values requires getting the type right
and knowing the field number. Both of these can be addressed at a later time.
Fixes #2143, at least as a first pass.
|
| |
|
|
|
|
| |
deprecate any fields that are currently using that type
|
|\
| |
| | |
Missed LIBPROTOC_EXPORT for GRPC added
|
| | |
|
| |
| |
| |
| | |
objectivec_helpers.h
|
|/ |
|
|\
| |
| | |
Cherry pick c# changes from master
|
| | |
|
|/ |
|
|
|
|
|
|
| |
This does not affect the generated code.
If we decide we want to apply attributes to generated types, we should start by
just reverting this change.
|
|
|
|
|
|
|
|
|
| |
I think this has caught everything.
I've left a stub for attributes to be applied to the types themselves, but we don't currently need anything.
Follow-up commit will include the changes to generated code itself.
Fixes #1671.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Overview of changes:
- A new C#-specific command-line option, legacy_enum_values to revert to the old behavior
- When legacy_enum_values isn't specified, we strip the enum name as a prefix, and PascalCase the value name
- A new attribute within the C# code so that we can always tell the original in-proto name
Regenerating the C# code with legacy_enum_values leads to code which still compiles and works - but
there's more still to do.
|
|
|
|
|
|
| |
enum value name
This will make it easier to change the enum value names, as it reduces the number of places they're used.
|
| |
|
| |
|
|
|
|
|
|
| |
This also renames generate_directories to base_namespace_specified; generating directories is the
immediate *effect* of specifying a base namespace, but with this change the options reflect what has been
specified rather than the effect. (There may be other effects in the future, of course.)
|
|
|
|
|
|
|
|
| |
This should have no behavioral changes at all.
This doesn't strictly enforce an 80-column limit, but removes the most egregious violations.
The indentation in the C# generator code is inconsistent in general, unfortunately - if we have
any good tools that can be trusted to reformat, I'd be happy to apply them.
|
|
|
|
|
|
|
|
|
|
|
| |
* `csharp_options`: Added `Options` to encapsulate generator options.
Supported options for now - file_extension, base_namespace
* `{Blah}Generator`: Now accept `Options*` as parameter to constructor
* `csharp_generator.cc`: Parse and populate options
* `Makefile.am`: Added `csharp_options.h`
* `extract_includes.bat.in`: Added `csharp_options.h`
Refactoring code to two commits. This is the first commit
|
|
|
|
| |
(Generated code changes in next commit.)
|
|
|
|
|
|
|
| |
Recently, descriptor.proto gained a GeneratedCodeInfo message, which means the generated code conflicts with our type.
Unfortunately this affects codegen as well, although this is a part of the public API which is very unlikely to affect hand-written code.
Generated code changes in next commit.
|
|
|
|
|
| |
On deserialization, missing values for message types
are replaced with a "default" message.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This addresses issue #1008, by creating a JsonFormatter which is private and only different
to JsonFormatter.Default in terms of reference equality.
Other plausible designs:
- The same, but expose the diagnostic-only formatter
- Add something to settings to say "I don't have a type registry at all"
- Change the behaviour of JsonFormatter.Default (bad idea IMO, as we really *don't* want the result of this used as regular JSON to be parsed)
Note that just trying to find a separate fix to issue #933 and using that to override Any.ToString() differently wouldn't work for messages that *contain* an Any.
Generated code changes follow in the next commit.
|
|
|
|
|
|
|
|
|
| |
There are corner cases where MessageDescriptor.{ClrType,Parser} will return null, and these are now documented. However, normally they *should* be implemented, even for descriptors of for dynamic messages. Ditto FieldDescriptor.Accessor.
We'll still need a fair amount of work to implement dynamic messages, but this change means that the public API will be remain intact.
Additionally, this change starts making use of C# 6 features in the files that it touches. This is far from exhaustive, and later PRs will have more.
Generated code changes coming in the next commit.
|
|
|
|
| |
This changes csharp_names.h, which will require a corresponding change in GRPC.
|
|
|
|
|
|
| |
generated types.
Generated code coming in next commit - in a subsequent PR I want to do a bit of renaming and redocumenting around this, in anticipation of DynamicMessage.
|
|
|
|
|
| |
Instead of having a Proto nested namespace to avoid conflicts between the descriptor-holding static class and message classes, just append "Reflection" to the name.
Generated code changes (and corresponding manual changes) in following commit.
|
|
|
|
|
|
| |
This fixes issue #832.
Generated code changes in next commit.
|
|
|
|
| |
The included C# test will fail until the regenerated code is used, which is in the next commit.
|
|\
| |
| | |
Expose GetOutputFile in csharp_names.h
|
| |
| |
| |
| |
| |
| | |
This could be tidied up significantly, and at some point we will want to parse the markdown and generate more appropriate XML - but this is definitely better than nothing.
Generated code changes coming in next commit.
|
| | |
|
| |
| |
| |
| | |
(Generated code changes coming next...)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are now summaries for:
- The Types nested class (which holds nested types)
- The file descriptor class for each proto
- The enum generated for each oneof
(Also fixed two typos.)
Generated code in next commit.
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces a new C# option, base_namespace.
If the option is not specified, the behaviour is as before: no directories are generated.
If the option *is* specified, all C# namespaces must be relative to the base namespace, and the directories are generated relative to that namespace.
Example:
- Any.proto declares csharp_namespace = "Google.Protobuf.WellKnownTypes"
- We build with --csharp_out=Google.Protobuf --csharp_opt=base_namespace=Google.Protobuf
- The Any.cs file is generated in Google.Protobuf/WellKnownTypes (where it currently lives)
We need a change to descriptor.proto before this will all work (it wasn't in the right C# namespace) but that needs the other descriptors to be regenerated too. See next commit...
|
| |
|