- User Since
- Mar 23 2016, 8:38 AM (251 w, 6 d)
- Compile regex only once
From what I understand this means D91378 is no longer necessary. thanks!
- Add a comment for the orphan in the doc page.
Sun, Jan 17
Fri, Jan 15
Wed, Jan 13
I merged the Python API now into the normal website (see https://teemperor.de/pub/lldb_website/python_api.html# for how this looks). So cross-referencing and the website search now work for everything.
- Merged Python API and normal website.
Tue, Jan 12
- Use the old output directory name.
I generated the current website here: https://teemperor.de/pub/sbapi/
Fri, Jan 8
LGTM modulo the warning messages still referencing 2 instead of 3.
Wed, Jan 6
Dec 18 2020
Some comments about that this still prints 255, but otherwise this is looking good.
Dec 17 2020
I just realized that I got the char sign also mixed up. It's an unsigned char in LLDB, so the 255 is wrong (But I believe our char signedness handling is not correct in any C language). But the fact that we don't print YES/NO for that bitfield is right (just the int value is wrong).
I think the proper fix here is to warn about BOOL bitfields with size 1 if BOOL is a typedef for signed char. I can make a Clang warning for that. I guess on the LLDB side we should make it clear that BOOL here has an invalid value (and then print the int value as we currently do)?
Whether BOOL is signed char or bool is apparently depending on the architecture (???). See ClangExpressionSourceCode::GetText, Clang's __OBJC_BOOL_IS_BOOL macro and then there is also some preprocessor shenanigans for non-Clang ObjC (?) in the objc.h header from what I can see. Whether C++ is active is never actually checked anywhere (the bool type is coming from stdbool.h which is unconditionally included by objc.h).
Dec 16 2020
Dec 15 2020
Dec 14 2020
I believe rsmith is in GMT-8, so I assume this won't get a fix soon and I went ahead and reverted in 22ccdb787024e954318e35fcf904fd4fa36f5679
Dec 11 2020
Dec 10 2020
Dec 9 2020
There area few failures once I actually create the lookup table, so I put this on my TODO list.
LGTM. I assume that's the result of investigating Vedant's zombie generation script?
- Clarify ClangASTContext destructor code.
Dec 8 2020
- Expanded test with mixed debug info/module types (thanks Shafik!)
- Now using one setting with a backing enum (Thanks Jonas)
- Gave up on imposing my doxygen code style on the project (Thanks Adrian).
- Expanded test (Thanks Shafik)
I'll go ahead and land this to unbreak the bots using Clang modules. Just using this for post-commit review.
So the only downside I can see is that the ASTImporter is no longer considering non-imported declarations in the To context (which are not known to the SharedState) for merging? Given that we most likely never want this to happen within LLDB, this seems like a straightforward change.
There are several LLDB tests failing with this change. The TestImportBaseClassWhenClassHasDerivedMember.py is probably the only relevant one. The others are probably failing for the same reason but with a more convoluted setup. I looked into the failure and it seems this patch is now skipping the workaround in ImportContext that was introduced in D78000 (as the Importer.GetAlreadyImportedOrNull will give us a DeclContext and then we just use that as-is). If you remove the if (!DC || !LexicalDC) before the if ((Err = ImportDeclContext(D, DC, LexicalDC))) this should keep the old behaviour.
Dec 7 2020
LGTM, thanks! Bonus points for the emotional rollercoaster in the review history.
I had to add a lldb-noinit alias that creates a completely uninitialized lldb (as the default init file for the tests sets a cache path).
Dec 4 2020
I was a bit too quick with updating that one, doesn't seem to pass the tests. Two small fixes: