3party/googletest
0
0
Fork 0
mirror of https://github.com/google/googletest.git synced 2024-12-26 09:31:02 +08:00
Code Issues Projects Releases Wiki Activity

Remove Googletest FAQ entry for obsolete ProtocolMessageEquals and ProtocolMessageEquiv

Browse Source 
* These long-dead variants of the proto matchers don't exist in the current version of Googletest.
* No evidence of external usage: [the only external references I see](https://www.google.com/search?q=%22protocolmessageequals%22+OR+%22protocolmessageequals%22) are copies of this guide. Possibly they were already removed by the time Googletest was publicly released.

PiperOrigin-RevId: 565358401
Change-Id: I61379b7333fa8ee19cd5520caedf2c539f54c2d7
This commit is contained in:
Michael Hirshleifer 2023-09-14 07:12:44 -07:00 committed by Copybara-Service
parent af5ddbde4d
commit 728ec52d21
1 changed files with 0 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
docs/faq.md
View File

@ -128,27 +128,6 @@ both approaches a try. Practice is a much better way to grasp the subtle
differences between the two tools. Once you have some concrete experience, you
can much more easily decide which one to use the next time.
## I got some run-time errors about invalid proto descriptors when using `ProtocolMessageEquals`. Help!
{: .callout .note}
**Note:** `ProtocolMessageEquals` and `ProtocolMessageEquiv` are *deprecated*
now. Please use `EqualsProto`, etc instead.
`ProtocolMessageEquals` and `ProtocolMessageEquiv` were redefined recently and
are now less tolerant of invalid protocol buffer definitions. In particular, if
you have a `foo.proto` that doesn't fully qualify the type of a protocol message
it references (e.g. `message<Bar>` where it should be `message<blah.Bar>`), you
will now get run-time errors like:
```
... descriptor.cc:...] Invalid proto descriptor for file "path/to/foo.proto":
... descriptor.cc:...] blah.MyMessage.my_field: ".Bar" is not defined.
```
If you see this, your `.proto` file is broken and needs to be fixed by making
the types fully qualified. The new definition of `ProtocolMessageEquals` and
`ProtocolMessageEquiv` just happen to reveal your bug.
## My death test modifies some state, but the change seems lost after the death test finishes. Why?
Death tests (`EXPECT_DEATH`, etc) are executed in a sub-process s.t. the