This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Add MockTypeSystem and some basic unit test for CompilerType
AcceptedPublic

Authored by teemperor on Nov 27 2019, 2:12 AM.

Details

Reviewers
labath
Summary

There are a lot of classes using TypeSystem in some way (mostly indirectly
through CompilerType) and we can't really unittest this code at the moment without
having some kind of mock TypeSystem.

This adds a MockTypeSystem to the TestingSupport that provides a stub implementation
for all the deleted functions. Also adds a very basic CompilerTest that just uses the MockTypeSystem
as a simple TypeSystem placeholder.

Diff Detail

Event Timeline

teemperor created this revision.Nov 27 2019, 2:12 AM

I think this should go into TestingSupport/Symbol (new folder) similar to how NativeProcessUtils.h is in TestingSupport/Host (to avoid the basic testing support functionality depending on the whole world).

It's not obvious how you intend to use this class, but instead of defining all methods as llvm_unreachable you could consider mocking them via gmock. This way you wouldn't need to create a separate mock class for each use case, and could instead "program" the mocks via something like EXPECT_CALL(my_mock, GetNumVirtualBaseClasses(42)).Return(47);.

teemperor updated this revision to Diff 231226.Nov 27 2019, 5:29 AM

I tried moving this to gmock, but after an hour of not being able to even declare a simple virtual method due to issues like this I don't think this approach is really practical. gmock is a nightmare to debug with all these completely undocumented macros. If gmock was actually documented and would work, then I think we should use it. But at the current state I can't even get it to compile code it seems without having to diagnostic-disable hacks, so that's a no-go

Also we anyway also want to model things like fake type hierarchies that one can traverse via CompilerType/TypeSystem (e.g. when doing completions like in the Variable completion code), so simple mocking is anyway not really the right fit.

Changes:

  • Renamed MockTypeSystem -> FakeTypeSystem to reflect that this is not just mocking.
  • Moved TestingSupport library to its own subdirectory and library that links against Symbol.
  • Replaced llvm_unreachable in the unimplemented functions with macro to make migration easier if someone has a better approach to handling them.
labath accepted this revision.Nov 27 2019, 8:31 AM

I tried moving this to gmock, but after an hour of not being able to even declare a simple virtual method due to issues like this I don't think this approach is really practical. gmock is a nightmare to debug with all these completely undocumented macros. If gmock was actually documented and would work, then I think we should use it. But at the current state I can't even get it to compile code it seems without having to diagnostic-disable hacks, so that's a no-go

That's easy to work around by just not using any "override" keywords in the class which defines the mock methods. This is unfortunate, but I don't think it's a showstopper. If anything, it's a reason for updating to a newer gmock version, since that's solved there.

I'm not sure what documentation you were looking at, but overall, I've found googlemock to be documented pretty well (definitely better than llvm or lldb).

So, I don't think either of these things are a reason to *not use* it. However, they are not reasons for *using* it either. Gmock is good for some cases, and not so good for others. Right now it's not clear to me what kind of uses you have in mind, but in the simple tests you have in this patch, it is true that gmock would not provide any value. We can revisit that decision later, or add a new gmock-based type system class (there's nothing stopping us from having more than one).

Also we anyway also want to model things like fake type hierarchies that one can traverse via CompilerType/TypeSystem (e.g. when doing completions like in the Variable completion code), so simple mocking is anyway not really the right fit.

Yes, that is something where gmock would not be particularly useful..

Changes:

  • Renamed MockTypeSystem -> FakeTypeSystem to reflect that this is not just mocking.
  • Moved TestingSupport library to its own subdirectory and library that links against Symbol.

Thanks.

  • Replaced llvm_unreachable in the unimplemented functions with macro to make migration easier if someone has a better approach to handling them.

I don't think this brings any value (the "verboseness" of llvm_unreachable("unimplemented") was not my main issue with this approach). Let's just revert that.

lldb/unittests/TestingSupport/Symbol/FakeTypeSystem.h
22

I don't think this is worth a macro. If you really want to save a couple of characters you can just declare a unimplemented static member function...

This revision is now accepted and ready to land.Nov 27 2019, 8:31 AM