This is an archive of the discontinued LLVM Phabricator instance.

Make operator==s consistent between c++ and python APIs
ClosedPublic

Authored by labath on Mar 26 2019, 7:27 AM.

Details

Summary

modify-python-lldb.py had code to insert python equality operators to
some classes. Some of those classes already had c++ equality operators,
and some didn't.

This makes the situation more consistent, by removing all equality
handilng from modify-python-lldb. Instead, I add c++ operators to
classes where they were missing, and expose them in the swig interface
files so that they are available to python too.

The only tricky case was the SBAddress class, which had an operator==
defined as a free function, which is not handled by swig. This function
cannot be removed without breaking ABI, and we cannot add an extra
operator== member, as that would make equality comparisons ambiguous.
For this class, I define a python eq function by hand and have it
delegate to the operator!=, which I have defined as a member function.

This isn't fully NFC, as the semantics of some equality functions in
python changes slightly, but I believe it changes for the better (e.g.,
previously SBBreakpoint.eq would consider two breakpoints with the
same ID as equal, even if they belonged to different targets; now they
are only equal if they belong to the same target).

Event Timeline

labath created this revision.Mar 26 2019, 7:27 AM
labath marked 2 inline comments as done.Mar 26 2019, 7:33 AM
labath added inline comments.
include/lldb/API/SBAddress.h
34–37

A different solution to this could be to still keep the free operator== defined, but do not expose it in the header. Then we could define a member operator==, without things being ambiguous. The people who build against old headers will still find the free operator== in the shared library, and people who use the new headers will start using the member operator==.

source/API/SBAddress.cpp
66–70

@JDevlieghere: you might be interested to know that this function is not intercepted by the api recorder. (This could be another argument for the "private free operator==" idea I mention above, as it would mean we don't need to add special code to intercept free functions.)

zturner accepted this revision.Apr 1 2019, 1:33 PM
This revision is now accepted and ready to land.Apr 1 2019, 1:33 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptApr 2 2019, 3:17 AM