-
Notifications
You must be signed in to change notification settings - Fork 15.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python JSON parser: Ignore invalid enum string values if ignore_unknown_fields is set #15887
Conversation
|
||
def testParseErrorForUnknownEnumValue_ScalarWithoutIgnore_Proto2(self): | ||
message = json_format_pb2.TestNumbers() | ||
self.assertRaisesRegexp( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed by using assertRaisesRegex
(without p
at the end) which is consistent with the rest of the file.
@@ -114,3 +115,11 @@ enum EnumValue { | |||
message TestDefaultEnumValue { | |||
optional EnumValue enum_value = 1 [default = DEFAULT]; | |||
} | |||
|
|||
message TestEnumMap { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed by renaming this message.
cb25010
to
277e212
Compare
Rebased with upstream due to a conflict with an added conformance test (0fa67a9) that we now fixed as well. I used force-push since I don't believe review started already. |
To over-communicate, this is now ready to review! |
@acozzette thank you for your time! I don't have permissions to merge the PR -- let me know if there are any other next steps for me here. |
@antongrbin Sorry for the delay but would you mind rebasing your PR (or merging main into it)? There was a test run added just a few days ago and for technical reasons our sync process can't proceed until it sees that the test is passing. |
06c8485
to
171b27e
Compare
@acozzette let me know if there is anything I can do with the CI failure for
|
Sorry for the hassle but would you mind merging main into your branch one more time? I'm pretty sure that test failure is unrelated to your change, and it might have been fixed on main already. |
@acozzette, done -- merged latest main here. No hassle at all -- I understand this is not a simple repo. |
Thanks! Unfortunately the failure is still there: |
@acozzette friendly ping :) Not that I am blocked on this (we are running a fork with this fix already), but would like to stop thinking about it sooner than later :) |
When building with `-Dprotobuf_BUILD_SHARED_LIBS=ON`, we currently put all test protos into their own shared library. PR #15887 seems to be pushing us over a limit on the number of exported symbols so that this library no longer links successfully, though. This change fixes that problem by always building the test protos into a static library. This should be fine since it's purely for testing and not meant to be installed. The only things that depend on it are executables, so we don't need to worry about ODR violations. PiperOrigin-RevId: 617666678
When building with `-Dprotobuf_BUILD_SHARED_LIBS=ON`, we currently put all test protos into their own shared library. PR #15887 seems to be pushing us over a limit on the number of exported symbols so that this library no longer links successfully, though. This change fixes that problem by always building the test protos into a static library. This should be fine since it's purely for testing and not meant to be installed. The only things that depend on it are executables, so we don't need to worry about ODR violations. PiperOrigin-RevId: 617666678
When building with `-Dprotobuf_BUILD_SHARED_LIBS=ON`, we currently put all test protos into their own shared library. PR #15887 seems to be pushing us over a limit on the number of exported symbols so that this library no longer links successfully, though. This change fixes that problem by always building the test protos into a static library. This should be fine since it's purely for testing and not meant to be installed. The only things that depend on it are executables, so we don't need to worry about ODR violations. PiperOrigin-RevId: 617666678
When building with `-Dprotobuf_BUILD_SHARED_LIBS=ON`, we currently put all test protos into their own shared library. PR #15887 seems to be pushing us over a limit on the number of exported symbols so that this library no longer links successfully, though. This change fixes that problem by always building the test protos into a static library. This should be fine since it's purely for testing and not meant to be installed. The only things that depend on it are executables, so we don't need to worry about ODR violations. PiperOrigin-RevId: 617666678
When building with `-Dprotobuf_BUILD_SHARED_LIBS=ON`, we currently put all test protos into their own shared library. PR #15887 seems to be pushing us over a limit on the number of exported symbols so that this library no longer links successfully, though. This change fixes that problem by always building the test protos into a static library. This should be fine since it's purely for testing and not meant to be installed. The only things that depend on it are executables, so we don't need to worry about ODR violations. PiperOrigin-RevId: 617666678
When building with `-Dprotobuf_BUILD_SHARED_LIBS=ON`, we currently put all test protos into their own shared library. PR #15887 seems to be pushing us over a limit on the number of exported symbols so that this library no longer links successfully, though. This change fixes that problem by always building the test protos into a static library. This should be fine since it's purely for testing and not meant to be installed. The only things that depend on it are executables, so we don't need to worry about ODR violations. PiperOrigin-RevId: 617666678
When building with `-Dprotobuf_BUILD_SHARED_LIBS=ON`, we currently put all test protos into their own shared library. PR #15887 seems to be pushing us over a limit on the number of exported symbols so that this library no longer links successfully, though. This change fixes that problem by always building the test protos into a static library. This should be fine since it's purely for testing and not meant to be installed. The only things that depend on it are executables, so we don't need to worry about ODR violations. PiperOrigin-RevId: 617929396
@antongrbin Sorry again for all the delays on this. I was able to get in a fix for the failing CMake test, so if you wouldn't mind merging main again then hopefully I can finally merge this. |
@acozzette no worries! Merged with upstream :) Thank you for fixing the problem!! |
…wn_fields is set (protocolbuffers#15887) # Motivation This PR fixes failing conformance tests for python with name `IgnoreUnknownEnumStringValue`. The JSON parsing spec was discussed in protocolbuffers#7392. Recent equivalent changes for other languages: * Swift: apple/swift-protobuf#1345 * C#: protocolbuffers#15758 # Changes - 1st commit is a noop refactoring to make relevant _ConvertScalarFieldValue invocations localized - 2nd commit introduces the child exception of `ParseError` named `EnumStringValueParseError` which is suppressed if `ignore_unknown_fields` is set - 3rd commit updates the conformance test failure lists Closes protocolbuffers#15887 COPYBARA_INTEGRATE_REVIEW=protocolbuffers#15887 from noom:anton/7392/fix-python-test fbcc93a PiperOrigin-RevId: 619288323
When building with `-Dprotobuf_BUILD_SHARED_LIBS=ON`, we currently put all test protos into their own shared library. PR protocolbuffers#15887 seems to be pushing us over a limit on the number of exported symbols so that this library no longer links successfully, though. This change fixes that problem by always building the test protos into a static library. This should be fine since it's purely for testing and not meant to be installed. The only things that depend on it are executables, so we don't need to worry about ODR violations. PiperOrigin-RevId: 617929396
…wn_fields is set (protocolbuffers#15887) # Motivation This PR fixes failing conformance tests for python with name `IgnoreUnknownEnumStringValue`. The JSON parsing spec was discussed in protocolbuffers#7392. Recent equivalent changes for other languages: * Swift: apple/swift-protobuf#1345 * C#: protocolbuffers#15758 # Changes - 1st commit is a noop refactoring to make relevant _ConvertScalarFieldValue invocations localized - 2nd commit introduces the child exception of `ParseError` named `EnumStringValueParseError` which is suppressed if `ignore_unknown_fields` is set - 3rd commit updates the conformance test failure lists Closes protocolbuffers#15887 COPYBARA_INTEGRATE_REVIEW=protocolbuffers#15887 from noom:anton/7392/fix-python-test fbcc93a PiperOrigin-RevId: 619288323
Is there a way now to use |
No, for the purposes of JSON parsing an unknown enum string is considered an unknown field. |
Motivation
This PR fixes failing conformance tests for python with name
IgnoreUnknownEnumStringValue
.The JSON parsing spec was discussed in #7392.
Recent equivalent changes for other languages:
Changes
ParseError
namedEnumStringValueParseError
which is suppressed ifignore_unknown_fields
is set