Commit
a85e676916b6babe9a5479ad3425ccce32f1ecaa
by suc-daniil[NFC][InstCombine] Add tests that show a number of canonicalization opportunities Reviewers: spatel, RKSimon, lebedev.ri, apilipenko Reviewed-By: apilipenko Tags: #llvm Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D68263
|
 | llvm/test/Transforms/InstCombine/phi-equal-incoming-pointers.ll |
Commit
bd7d9a85b8b09c945b98d374cc37cb374db012e6
by Raphael Isemann[lldb] Check if we actually have a Clang type in ObjCLanguage::GetPossibleFormattersMatches We call IsPossibleDynamicType but we also need to check if this is a Clang type, otherwise other languages with dynamic types (like Swift) might end up being interpreted as potential Obj-C dynamic types.
|
 | lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp |
Commit
6cc853b416a2b0d0b435d145988c5d3b6faaa712
by Raphael Isemann[lldb][NFC] Remove unused CompilerType::IsPossibleCPlusPlusDynamicType Reviewers: davide, xiaobai Reviewed By: davide, xiaobai Subscribers: davide, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70074
|
 | lldb/include/lldb/Symbol/CompilerType.h |
Commit
52f3a2faf92c4d8efd0e626d52d5f64b7c5d468f
by Raphael Isemann[lldb][NFC] Move LLVM RTTI implementation from enum to static ID variable Summary: swift-lldb currently has to patch the ExpressionKind enum to add support for Swift expressions. If we implement LLVM's RTTI with a static ID variable instead of a centralised enum we can drop that patch. Reviewers: labath, davide Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #upstreaming_lldb_s_downstream_patches, #lldb Differential Revision: https://reviews.llvm.org/D70070
|
 | lldb/source/Expression/UserExpression.cpp |
 | lldb/source/Plugins/ExpressionParser/Clang/ClangFunctionCaller.h |
 | lldb/include/lldb/Expression/LLVMUserExpression.h |
 | lldb/source/Expression/FunctionCaller.cpp |
 | lldb/source/Plugins/ExpressionParser/Clang/ClangFunctionCaller.cpp |
 | lldb/include/lldb/Expression/UtilityFunction.h |
 | lldb/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.cpp |
 | lldb/include/lldb/Expression/FunctionCaller.h |
 | lldb/include/lldb/Expression/UserExpression.h |
 | lldb/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.h |
 | lldb/source/Expression/LLVMUserExpression.cpp |
 | lldb/source/Expression/Expression.cpp |
 | lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp |
 | lldb/source/Expression/UtilityFunction.cpp |
 | lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.h |
 | lldb/include/lldb/Expression/Expression.h |
Commit
874b6495b5fd6d7e2dc91d6a756eea67486ea7bb
by Raphael Isemann[lldb] Add missing include to ObjCLanguage.cpp to fix build
|
 | lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp |
Commit
a75f8d98d7ac9e557b238a229a9a2647c71feed1
by paulhoad[clang-format] [PR36294] AlwaysBreakAfterReturnType works incorrectly for some operator functions Summary: https://bugs.llvm.org/show_bug.cgi?id=36294 Addressing bug related to returning after return type not being honoured for some operator types. ``` $ bin/clang-format --style="{BasedOnStyle: llvm, AlwaysBreakAfterReturnType: TopLevelDefinitions}" /tmp/foo.cpp class Foo { public: bool operator!() const; bool operator<(Foo const &) const; bool operator*() const; bool operator->() const; bool operator+() const; bool operator-() const; bool f() const; }; bool Foo::operator!() const { return true; } bool Foo::operator<(Foo const &) const { return true; } bool Foo::operator*() const { return true; } bool Foo::operator->() const { return true; } bool Foo::operator+() const { return true; } bool Foo::operator-() const { return true; } bool Foo::f() const { return true; } ``` Reviewers: mitchell-stellar, klimek, owenpan, sammccall, rianquinn Reviewed By: sammccall Subscribers: merge_guards_bot, cfe-commits Tags: #clang-format, #clang-tools-extra, #clang Differential Revision: https://reviews.llvm.org/D69573
|
 | clang/unittests/Format/FormatTest.cpp |
 | clang/lib/Format/TokenAnnotator.cpp |
Commit
a9018fddf9ba17e53a35674bf0a93e78382c4c23
by dave[X86] Add more add/sub carry tests Preparation for: https://reviews.llvm.org/D70079 https://reviews.llvm.org/D70077
|
 | llvm/test/CodeGen/SystemZ/int-uadd-03.ll |
 | llvm/test/CodeGen/X86/subcarry.ll |
 | llvm/test/CodeGen/X86/addcarry.ll |
 | llvm/test/CodeGen/SystemZ/int-usub-03.ll |
Commit
ebe2f56030458e7a4c2375c6d92a48f0ed01eb5b
by pavelDWARFDebugLoclists: add location list "interpretation" logic Summary: This patch extracts the logic for computing the "absolute" locations, which was partially present in the debug_loclists dumper, completes it, and moves it into a separate function. This makes it possible to later reuse the same logic for uses other than dumping. The dumper is changed to reuse the location list interpreter, and its format is changed somewhat. In "verbose" mode it prints the "raw" value of a location list, the interpreted location (if available) and the expression itself. In non-verbose mode it prints only one of the location forms: it prefers the interpreted form, but falls back to the "raw" format if interpretation is not possible (for instance, because we were not given a base address, or the resolution of indirect addresses failed). This patch also undos some of the changes made in D69672, namely the part about making all functions static. The main reason for this is that I learned that the original approach (dumping only fully resolved locations) meant that it was impossible to rewrite one of the existing tests. To make that possible (and make the "inline location" dump work in more cases), I now reuse the same dumping mechanism as is used for section-based dumping. As this required having more objects know about the various location lists classes, it seemed like a good idea to create an interface abstracting the difference between them. Therefore, I now create a DWARFLocationTable class, which will serve as a base class for the location list classes. DWARFDebugLoclists is made to inherit from that. DWARFDebugLoc will follow. Another positive effect of this change is that section-based dumping code will not need to use templates (as originally) envisioned, and that the argument lists of the dumping functions become shorter. Reviewers: dblaikie, probinson, JDevlieghere, aprantl, SouraVX Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70081
|
 | llvm/test/tools/llvm-dwarfdump/X86/debug_loclists.s |
 | llvm/include/llvm/DebugInfo/DWARF/DWARFDebugLoc.h |
 | llvm/lib/DebugInfo/DWARF/DWARFDie.cpp |
 | llvm/test/DebugInfo/X86/loclists-dwp.ll |
 | llvm/test/tools/llvm-dwarfdump/X86/debug_loc_dwo.s |
 | llvm/test/tools/llvm-dwarfdump/X86/debug_loclists_startx_length.s |
 | llvm/lib/DebugInfo/DWARF/DWARFContext.cpp |
 | llvm/test/CodeGen/X86/debug-loclists.ll |
 | llvm/lib/DebugInfo/DWARF/DWARFDebugLoc.cpp |
 | llvm/include/llvm/DebugInfo/DWARF/DWARFLocationExpression.h |
 | llvm/test/DebugInfo/X86/fission-ranges.ll |
Commit
ec4c96d68566debcc4588c4189b4ef8a5f78729a
by Raphael Isemann[lldb][NFC] Simplify a return in ThreadPlanStepInRange::DefaultShouldStopHereCallback We know should_stop_here is false here, so we might as well return false directly.
|
 | lldb/source/Target/ThreadPlanStepInRange.cpp |