tree 6762e82824ba513297723d65fa838e7b6babb063
parent 6d516eb8c78ccc70ab300fe05474fb71ff7742f5
author Pavel Labath <pavel@labath.sk> 1550216826 +0000
committer Pavel Labath <pavel@labath.sk> 1550216826 +0000

Fix lldb-server test suite for python3

Summary:
This patch finishes the python3-ification of the lldb-server test suite.
It reverts the partial attempt in r352709 to encode/decode the string
via utf8 before writing to the socket. This wasn't enough because the
gdb-remote protocol can sometimes (but not very often) carry binary
data, and the utf8 codec chokes on that. Instead I add utility functions
to the "seven" module for performing "identity" transformations on the
byte data. This basically drills back the hole in the python type system
that the string/bytes distinction was supposed to plug. That is not
ideal, but was the best solution of the alternatives I could come up
with. The options I considered were:
- make use of the type system to add type safety to the test suite: This
  required making a lot of changes to the test suite, since most of the
  strings would now become byte objects instead, and it was not even
  fully clear to me where to draw the line. One extreme solution would
  be to just use byte objects everywhere, as the protocol doesn't
  support non-ascii characters anyway. However, this appeared to be:
  a) weird, because most of the protocol actually deals with strings,
     but we would have to prefix everything with 'b'
  b) clunky, because the handling of the bytes objects is sufficiently
     different in PY2 and PY3 (e.g. b'a'[0] is a string in PY2, but an
     int in PY3).
- using the latin1 codec (which gives an identity transformation for the
  first 256 code points of unicode) instead of the custom
  bytes_to_string functions. This almost could work, but it was still
  slightly different between python 2 and 3, because in PY2 in would
  return a unicode object, which would then cause problems when
  combined with regular strings if it contained 8-bit chars.

With this in mind, I think the best solution for the time being is to
just coerce everything into the string type as early as possible, and
have things proceed indentically on both python versions. Once we stop
supporting python3, we can revisit the idea of using bytes objects more
prevasively.

Reviewers: davide, zturner, serge-sans-paille

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D58177

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@354106 91177308-0d34-0410-b5e6-96231b3b80d8