Expected Identifier Error with 2.6.1 on Mac OS X 10.10 #549
Comments
|
For 2.6.x, we probably will not make new releases. The version number has been alpha because we have some more languages to support. If you are using C++/Java/Python, they are mature enough and can be relied on. Internally in Google they are already used on production machines before changes are merged to this github repo. |
|
Okay. Thanks! I'll just use the latest alpha then. |
|
While this issue is fixed now, a similar situation happens when I tried to extend FieldOptions in my proto file. Basically, I import https://github.com/google/protobuf/blob/master/src/google/protobuf/descriptor.proto in my.proto file. Then, after compile, my.pb.h includes the pre-compiled https://github.com/google/protobuf/blob/master/src/google/protobuf/descriptor.pb.h which does not have the |
(*Generator).DefaultPackageName returns either a qualified ("pkg.name") or
unqualified ("name") name.
Prior to commit 9d4962b, it based this decision on whether the
name was in the package we're generating code for. After this
commit, it bases this on whether the name is in the file we're
currently generating code for. i.e., what was once an invariant
across all files is no longer.
This is mostly fine, except for one case: We run the generator
across files we do not generate code for, in order to build a list
of symbols used to generate code for public imports. This change
caused some of those symbols to no longer be qualified.
In particular, this causes bad generation for wrapper types of
publicly imported messages that contain a field whose type is
another message in the same publicly imported package.
Fix this. Clean up some effectively dead code in SetPackageNames
at the same time. Fix tests to catch this case. (It wouldn't have
caught it anyway, but imp.proto is supposed to contain a public import.
This seems to have been lost when exporting code to git. Fixed.)
(NFC) Refactored upbc header generation into smaller methods.
I get this error when compiling Spectrum XMPP Transports:
It's an error that's caused because TYPE_BOOL is already defined in ConditionalMacros.h on OS X. In the 3.0.x alphas you've fixed this already by adding:
However in 2.6.x it hasn't been applied there. I'd rather not use alpha software on a production machine. I've patched my local header file, and it fixes the compilation issue. Could you add it to 2.6.x as well while we wait for 3.0 to mature?
The text was updated successfully, but these errors were encountered: