summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/CompilerInstance.cpp
diff options
context:
space:
mode:
authorDavid L. Jones <dlj@google.com>2017-06-29 01:03:55 +0000
committerDavid L. Jones <dlj@google.com>2017-06-29 01:03:55 +0000
commitd59c9cd539abf29a5d02c16e60805bdde2e18bd3 (patch)
tree9a587fb1e496fdb5a2e54f035c892044097242be /clang/lib/Frontend/CompilerInstance.cpp
parent17277f13f048b528ce9e35db2cb58540f6180abd (diff)
downloadbcm5719-llvm-d59c9cd539abf29a5d02c16e60805bdde2e18bd3.tar.gz
bcm5719-llvm-d59c9cd539abf29a5d02c16e60805bdde2e18bd3.zip
[lit] Fix some convoluted logic around Unicode encoding, and de-duplicate across modules that used it.
Summary: In Python2 and Python3, the various (non-)?Unicode string types are sort of spaghetti. Python2 has unicode support tacked on via the 'unicode' type, which is distinct from 'str' (which are bytes). Python3 takes the "unicode-everywhere" approach, with 'str' representing a Unicode string. Both have a 'bytes' type. In Python3, it is the only way to represent raw bytes. However, in Python2, 'bytes' is an alias for 'str'. This leads to interesting problems when an interface requires a precise type, but has to run under both Python2 and Python3. The previous logic appeared to be correct in all cases, but went through more layers of indirection than necessary. This change does the necessary conversions in one shot, with documentation about which paths might be taken in Python2 or Python3. Reviewers: zturner, modocache Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D34793 llvm-svn: 306625
Diffstat (limited to 'clang/lib/Frontend/CompilerInstance.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud