From 728ec52d2167f61fad5672c3073d72d49a4482df Mon Sep 17 00:00:00 2001 From: Michael Hirshleifer Date: Thu, 14 Sep 2023 07:12:44 -0700 Subject: Remove Googletest FAQ entry for obsolete `ProtocolMessageEquals` and `ProtocolMessageEquiv` * 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 --- docs/faq.md | 21 --------------------- 1 file changed, 21 deletions(-) (limited to 'docs') diff --git a/docs/faq.md b/docs/faq.md index 90c2497..c942b5d 100644 --- a/docs/faq.md +++ b/docs/faq.md @@ -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` where it should be `message`), 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 -- cgit v1.1