Aug 13 2019
Aug 12 2019
I appreciate you adding more error handling. Thank you!
Aug 7 2019
Aug 6 2019
Aug 5 2019
Jul 31 2019
Jul 30 2019
Removed argument to GetScratchTypeSystems from SBTarget
Update GetScatchTypeSystems to account for changes to TypeSystem usage
Jul 29 2019
I think this change has introduced a dependence on x64.
I tried building with the 32b Visual Studio compiler and there are a number of undefined registers in registercontextwindows_x64.cpp.
This is because the version of _CONTEXT included by winnt.h is for x32 and not x64.
i.e., llvm-project\lldb\source\plugins\process\windows\common\x64\registercontextwindows_x64.cpp(297): error C2039: 'Rax': is not a member of '_CONTEXT'
Small logic change in SBModule
I have one remark about the consumeError+LLDB_LOG pattern. As for whether this is better than status quo or not, I still don't have an opinion on that. :)
Fix incorrect error logging pattern
Jul 26 2019
- Use Expected<TypeSystem&>
- Did some formatting
- Made error checking more explicit
I'm going to update this diff with what I changed to give y'all a better idea of what has been changed. I shoulda done that to begin with... :P
Jul 25 2019
After going through this and modifying this patch, I can't help but wonder if llvm::Optional<TypeSystem &> would be more appropriate. There are plenty of instances where it's not a hard error if you can't get a TypeSystem and the appropriate action is probably just to log and move on. I am conflicted because I like how Expected forces you to be more rigorous with error handling but I can't help but feel it is the wrong abstraction. Thoughts?
I think this is fine. Using .def files would be okay too, but I like the sanity checks that Jonas introduced in the LLDBPropertyDefEmitter
Jul 24 2019
Jul 23 2019
Jul 22 2019
Thanks for restoring them.
Jul 19 2019
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! :)
Jul 18 2019
All uses of this new function drop the error on the ground. Does that mean it doesn't matter? If it does, should we return an expected instead? Should we stop on the first error, or is it fine to overwrite when iterating over languages_for_expressions? It seems like the error handling needs some more work here.
Jul 17 2019
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 seems partly wrong to me. The point is that the Target holds scratch AST contexts for all the languages it supports. They are the central repository for the accumulation of effects of expressions evaluated while that target is alive. For instance, all the user defined types and variables go there. The Target also manages its lifecycle. For instance, in the swift case if there's a module that we can't import, we have to fall back to making an AST Context for each module we can successfully import and dispatching expressions to the appropriate one of those.
So all the Scratch AST Contexts are properly owned by the target.
This move doesn't keep all the clients from knowing they are getting their hands on a ClangASTContext, so it doesn't seem like it achieves much hiding. All it does is conceal the ownership of the scratch AST context for C-family languages.
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?
Jul 16 2019
Remove ClangASTContext header from Target.cpp
This definitely caused me some pain a few months ago. Thanks for adding this!
Jul 15 2019
Jul 12 2019