[Lldb-commits] [PATCH] D33083: [Expression parser] Look up module symbols before hunting globally

2017-05-10 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment. Bonus point for implementing a global symbol search that is aware of the above rules and can stop after step 1 if there are matches, and after step 2 if there are matches, etc. https://reviews.llvm.org/D33083 ___

[Lldb-commits] [PATCH] D33083: [Expression parser] Look up module symbols before hunting globally

2017-05-10 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment. In https://reviews.llvm.org/D33083#751836, @jingham wrote: > Actually, I take that back. Why do you have to call FindGlobalDataSymbol > twice? Shouldn't FindGlobalDataSymbol do that work for you. After all you > passed in the module. It should itself prefer

[Lldb-commits] [PATCH] D33083: [Expression parser] Look up module symbols before hunting globally

2017-05-10 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment. Actually, I take that back. Why do you have to call FindGlobalDataSymbol twice? Shouldn't FindGlobalDataSymbol do that work for you. After all you passed in the module. It should itself prefer symbols in the module... It also seems wrong that we're just picking the

[Lldb-commits] [PATCH] D33083: [Expression parser] Look up module symbols before hunting globally

2017-05-10 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment. Yes, this seems obviously right. https://reviews.llvm.org/D33083 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D33083: [Expression parser] Look up module symbols before hunting globally

2017-05-10 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment. There is a SymbolContext function sorts types based on the context contained in a SymbolContext. Seems like we should do the same thing here? See SymbolContext::SortTypeList(). https://reviews.llvm.org/D33083 ___

[Lldb-commits] [PATCH] D33083: [Expression parser] Look up module symbols before hunting globally

2017-05-10 Thread Sean Callanan via Phabricator via lldb-commits
spyffe created this revision. When it resolved symbol-only variables, the expression parser currently looks only in the global module list. It should prefer the current module. I've fixed that behavior by making it search the current module first, and only search globally if it finds

[Lldb-commits] [PATCH] D33025: [DWARF parser] Produce correct template parameter packs

2017-05-10 Thread Greg Clayton via Phabricator via lldb-commits
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. Very nice Repository: rL LLVM https://reviews.llvm.org/D33025 ___ lldb-commits mailing list lldb-commits@lists.llvm.org

[Lldb-commits] [PATCH] D33077: [TypeSystem] Fix inspection of Objective-C object types

2017-05-10 Thread Sean Callanan via Phabricator via lldb-commits
spyffe created this revision. `ptr_refs` exposed a problem in ClangASTContext's implementation; it uses an accessor to convert a `QualType` into an `ObjCObjectPointerType`, but the accessor is not fully general. `getAs()` is the safer way to go. I've added a test case that uses `ptr_refs` in

[Lldb-commits] [PATCH] D33035: Tool for using Intel(R) Processor Trace hardware feature

2017-05-10 Thread Kamil Rytarowski via Phabricator via lldb-commits
krytarowski added a comment. In https://reviews.llvm.org/D33035#751280, @clayborg wrote: > In https://reviews.llvm.org/D33035#751264, @krytarowski wrote: > > > Can we please use the generic process plugin code, not the specific Linux > > one? If the generic code is insufficient - we should

[Lldb-commits] [PATCH] D33035: Tool for using Intel(R) Processor Trace hardware feature

2017-05-10 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment. In https://reviews.llvm.org/D33035#751264, @krytarowski wrote: > Can we please use the generic process plugin code, not the specific Linux > one? If the generic code is insufficient - we should adjust it and alter > instances of it (Linux and BSD). There should be

[Lldb-commits] [PATCH] D33035: Tool for using Intel(R) Processor Trace hardware feature

2017-05-10 Thread Kamil Rytarowski via Phabricator via lldb-commits
krytarowski added a comment. Can we please use a generic process plugin code, not the specific Linux one? If the generic code is insufficient - we should adjust it and alter instances of it (Linux and BSD). https://reviews.llvm.org/D33035 ___

[Lldb-commits] [PATCH] D33035: Tool for using Intel(R) Processor Trace hardware feature

2017-05-10 Thread Greg Clayton via Phabricator via lldb-commits
clayborg requested changes to this revision. clayborg added a comment. This revision now requires changes to proceed. So we don't want clients of SBStructuredData to have to text scrape and write manual decoders. See my inlined comments on the minimal modifications we need to make to

[Lldb-commits] [PATCH] D33034: Tool for using Intel(R) Processor Trace hardware feature

2017-05-10 Thread Abhishek via Phabricator via lldb-commits
abhishek.aggarwal abandoned this revision. abhishek.aggarwal added a comment. Abandoning this change due to formatting problem with commit message. https://reviews.llvm.org/D33034 ___ lldb-commits mailing list lldb-commits@lists.llvm.org