[PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

jingham added inline comments. Comment at: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py:44 + +lldbutil.run_to_source_breakpoint(self, '// Break after co_yield', +lldb.SBFileSpec("main.cpp"

[PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

jingham added inline comments. Comment at: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py:15 + +class TestCoroutineHandle(TestBase): +def do_test(self, stdlib_type): aprantl wrote: > Nice test!

[PATCH] D91103: [tooling] Add support for fixits that indicate code will need reformatting

jingham added a comment. IIUC, the expression parser part of this change suppresses any Fixits that are clang-tidy type rewrites, is that right? If so that is indeed the correct behavior. But that fact that this change implements that behavior is entirely non-obvious at the call site. Could

[PATCH] D61438: [ASTImporter] Use llvm::Expected and Error in the importer API

jingham added a comment. IIUC, when Expected returns fails, it returns an Error object that might have information about what went wrong. Would it be possible to include the contents of that error n the log message? We often get "I can't run an expression in a really complex proprietary code

[PATCH] D44842: Add Parameters to DW_AT_name Attribute of Template Variables

jingham added a comment. Apparently this makes a global variable, so "frame var" wouldn't show it by default. What does "frame var -g" show? We would also need to get: (lldb) frame var -g crazy or something like it to work. "frame var" has its own parser to support "->" and ".". That doe

[PATCH] D44842: Add Parameters to DW_AT_name Attribute of Template Variables

jingham added a comment. @ormris Thanks! I you come up with some examples that test this, I can whip up an lldb test case (or you can if you are feeling adventurous.) If you want to try I'd be happy to give you a hand. Repository: rC Clang https://reviews.llvm.org/D44842 __

[PATCH] D44842: Add Parameters to DW_AT_name Attribute of Template Variables

jingham added a comment. I don't know off the top of my head. Did anybody working on this patch try printing variables in lldb with this name change, particularly global variables? Global lookups are particularly tricky, but it shouldn't be hard to check. You'd want to check that you can pri

[PATCH] D36347: New lldb python module for adding diagnostic breakpoints

jingham added a comment. Ack, my bad. I should remember not to rely on my memory... I thought at one point I was going to do it that way, then got annoyed I'd have to have "BreakpointDisableByName" etc... So apparently I made: SBTarget.FindBreakpointByName that takes a name & an SBBreakpoint

[PATCH] D36347: New lldb python module for adding diagnostic breakpoints

jingham added a comment. Note, BTW, Enrico also added a form of the command add that allows you to use a Python class to wrap the callable. That was in early 2015 so it's probably safe to use as well by now. That's even more convenient, and obviates the need for globals at all. One instance

[PATCH] D36347: New lldb python module for adding diagnostic breakpoints

jingham added a comment. Yes definitely use names for your breakpoints. It makes them easier to handle. Note starting a month or two ago you can set names to not get deleted except by an explicit gesture. That hasn't shown up in releases yet, but once you can rely on its being there, you can

[PATCH] D36347: New lldb python module for adding diagnostic breakpoints

jingham requested changes to this revision. jingham added a comment. This revision now requires changes to proceed. Use the form of the command that gets an SBExecutionContext, then you can avoid having to cache the target at all. Comment at: utils/clangdiag.py:98-100 +def the

[PATCH] D36347: Add new script to launch lldb and set breakpoints for diagnostics all diagnostics seen.

jingham added a comment. I can't see anything wrong with the SB API use here. I don't feel qualified to comment on the most effective workflow for an analysis I've never had to do, however. https://reviews.llvm.org/D36347 ___ cfe-commits mailing