Updating or removing lldb's copy of unittest2

I came across a minor bug writing some lldb-server tests where single
line diffs weren't handled correctly by unittest2. Turns out they are
in the latest version but the third_party/ version is older than that.

https://bugs.python.org/issue9174
unittest2: 96e432563d53 (though I think the
commit title is a mistake)

So I thought of cherry picking that one thing (assuming licensing
would allow me to), or even updating the whole copy (a lot of churn
for a single fix). Then I remembered that llvm in general has been
moving to Python3.

Looking at Building — The LLDB Debugger it doesn't
explicitly say Python2 isn't supported, but only Python3 is mentioned
so I assume lldb is now Python3 only.

If that is correct, is it worth me investigating using Python3's built
in unittest module instead, and removing our copy of unittest2?

Thanks,
David Spickett.

Hey David,

I came across a minor bug writing some lldb-server tests where single
line diffs weren’t handled correctly by unittest2. Turns out they are
in the latest version but the third_party/ version is older than that.

https://bugs.python.org/issue9174
https://hg.python.org/unittest2/rev/96e432563d53 (though I think the
commit title is a mistake)

So I thought of cherry picking that one thing (assuming licensing
would allow me to), or even updating the whole copy (a lot of churn
for a single fix). Then I remembered that llvm in general has been
moving to Python3.

I made an attempt to update the vendored unittest2 module in the past [1]. I diffed our vendored version with the release it was based on, updated the module and re-applied the changes. That was the easy part. The more intrusive part is that the testing framework changed the way it deals with expected failures. The old version used exceptions, while the new framework only looks at asserts that fail. I don’t remember the details, but we are relying on that mechanism somehow and as a result a bunch of test failed. The good thing is that this uncovered a few tests that were XFAILed but were really failing for unrelated reasons (i.e. Python throwing an exception because the test was plain wrong, rather than an assertion triggering or what was being tested not working). Anyway, hopefully this isn’t too much work, but at the time something more important came up and I haven’t had time to look at this again since.

Looking at https://lldb.llvm.org/resources/build.html it doesn’t
explicitly say Python2 isn’t supported, but only Python3 is mentioned
so I assume lldb is now Python3 only.

LLVM dropped support for Python 2 at the beginning of this year [2]. For LLDB specifically, I’ve asked for a bit more time before we start making “Python 2 incompatible” changes [3] as we still have to maintain Python 2 support internally. We’re actively working to drop that requirement.

If that is correct, is it worth me investigating using Python3’s built
in unittest module instead, and removing our copy of unittest2?

I’m in favor of dropping a vendored dependency, assuming of course we can get rid of the modification we rely on today. If we go that route I want to ask to land this after the 13 release is branched.

Cheers,
Jonas

[1] https://github.com/JDevlieghere/llvm-project/tree/update-vendored-unittest2
[2] https://lists.llvm.org/pipermail/llvm-dev/2020-December/147372.html
[3] https://lists.llvm.org/pipermail/lldb-dev/2020-August/016388.html

Thanks for the info.

If I get some time soon I can at least see what the current results
are with that updated module. If not I'll pitch in sometime after the
13 branch.