Page MenuHomePhabricator

[lldb] Actually enable wchar support in Editline when it is defined in the host config
ClosedPublic

Authored by teemperor on Dec 10 2019, 4:00 AM.

Details

Summary

Our Editline implementation in LLDB supports using the wchar interface of Editline which
should improve handling of unicode input when using Editline. At the moment we essentially
just ignore unicode input and echo the escaped unicode code point (\U1234) to the command line
(which we then also incorrectly treat as multiple characters, so console navigation is also broken afterwards).

This patch just adds the include to the host config file which already contains the LLDB_EDITLINE_USE_WCHAR
define to enable the Editline support (we just never included it in the file before). With this we now actually
echo back unicode characters on macOS and we no longer ignore unicode input. On Linux this doesn't
seem to improve the echoing back of characters but at least it fixes that we ignore unicode input.

Diff Detail

Event Timeline

teemperor created this revision.Dec 10 2019, 4:00 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 10 2019, 4:00 AM

If anyone wants to test this pre-commit, that would be appreciated as I fear we'll find some Editline implementations that will freak out over this patch. I tested this on Arch Linux and macOS.

teemperor retitled this revision from [lldb] Actually enabled wchar support in Editline when it is defined in the host config to [lldb] Actually enable wchar support in Editline when it is defined in the host config.Dec 10 2019, 4:19 AM
teemperor edited the summary of this revision. (Show Details)Dec 10 2019, 4:39 AM
labath accepted this revision.Dec 10 2019, 4:43 AM

Looks like there are still some issues with echoing unicode characters on linux, but this is still an improvement over status quo everywhere, so I see no reason to hold it up over that.

lldb/packages/Python/lldbsuite/test/iohandler/unicode/TestUnicode.py
25–27

I'd recommend using self.expect here. Right now the only difference is that it will do an additional expect_prompt after the command (which could possible help with the stability of this test, but probably won't make a difference), but the command may gain additional improvements over time.

This revision is now accepted and ready to land.Dec 10 2019, 4:43 AM
This revision was automatically updated to reflect the committed changes.