- User Since
- Mar 21 2017, 11:50 AM (121 w, 5 d)
Fri, Jul 19
Actually from the looks of it, I completely misunderstood what's going on here. It looks like AddToMap should only be called by things that hold the mutex, meaning that this change isn't actually necessary. I do think that makes this code kind of frustrating to understand though. Closing.
Excellent, thanks for taking care of this! :)
Thu, Jul 18
Wed, Jul 17
Yes, I agree that replacing ClangASTContext uses with TypeSystem would be the right thing to do, and it's what I plan on doing next. There are instances where you really do want a ClangASTContext (e.g. in plugins related to clang expression parsing and objc), and so having a convenience function like this means you don't have to cast the result of every call. This is similar to ObjCLanguageRuntime::Get. I don't mind abandoning this patch though.
This is a pretty interesting use case to say the least. I don't see an issue with it though, so go for it.
I think that this is a good change overall to do but the name LLDB_USE_SYSTEM_DEBUGSERVER is kind of a confusing to me. The name itself doesn't really convey to me that the system debugserver is going to be used for just testing. Before this change, that flag indicated that the system debugserver was going to be used for everything. Maybe you could change it to something like LLDB_TEST_WITH_SYSTEM_DEBUGSERVER?
Tue, Jul 16
Remove ClangASTContext header from Target.cpp
This definitely caused me some pain a few months ago. Thanks for adding this!
Mon, Jul 15
Fri, Jul 12
Thu, Jul 11
Remove documentation boilerplate
Can you add more context to this diff? I can't see the code surrounding the changes. You can get the whole context with something like git show -U9999.
Wed, Jul 10
Tue, Jul 9
Switch to using llvm::Optional<CompilerType> for the return type
Rename method from CalculateCompleteType to GetRuntimeType
Thanks for cleaning this up!
I like the idea a lot and the implementation looks alright. LGTM
Mon, Jul 8
This is awesome, thanks for doing this! I was also thinking about doing something like this at some point as well. :)
Wed, Jul 3
Thanks for doing this! :D
This patch looks fine to me overall. I'm unsure if LLDB has a guarantee about which NDK version its compatible with, but I'm alright with staying up to date with the latest release
Tue, Jul 2
Mon, Jul 1
Centralizing it means changing the classes that inherit from SymbolContextScope, so I will refactor that in a seaparate change and stack this change on top of that one.
Thu, Jun 27
- Implement @jingham's suggestion
- Change Function::GetLanguage to first guess the language from the name of the function you're in.
- Fix a bug in DWARFASTParserClang::ParseFunctionFromDWARF that qualifies ObjC methods as if they were C++ methods when parsing a function from an ObjC++ CU
@jingham: Okay, so I tried to do what you suggested and that solution doesn't work because of ObjC++. After looking into it, it looks like Variable and Function just ask the CompileUnit for the language type instead of determining it themselves meaning that we determining the Variable's language boils down to asking the CompileUnit for its language. That can probably be improved, but I think that just relying on the SymbolContextScope alone isn't yet sufficient. I think it would be worth it to ask the SymbolContextScope before trying all the loaded language runtimes though. Would you be okay with that solution?
Wed, Jun 26
Tue, Jun 25