|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1 |
|
| #
c34698a8 |
| 03-Feb-2022 |
Pavel Labath <[email protected]> |
[lldb] Rename Logging.h to LLDBLog.h and clean up includes
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging inf
[lldb] Rename Logging.h to LLDBLog.h and clean up includes
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging infrastructure). This worked because Log.h included Logging.h, even though it should.
After the recent refactor, it became impossible the two files include each other in this direction (the opposite inclusion is needed), so this patch removes the workaround that was put in place and cleans up all files to include the right thing. It also renames the file to LLDBLog to better reflect its purpose.
show more ...
|
|
Revision tags: llvmorg-15-init |
|
| #
a007a6d8 |
| 31-Jan-2022 |
Pavel Labath <[email protected]> |
[lldb] Convert "LLDB" log channel to the new API
|
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2 |
|
| #
4f14c17d |
| 10-Feb-2021 |
Shafik Yaghmour <[email protected]> |
[LLDB] Remove uneeded CopyType from BlockPointerSyntheticFrontEnd
BlockPointerSyntheticFrontEnd does a CopyType which results in it copying the type back into its own context. This will result in a
[LLDB] Remove uneeded CopyType from BlockPointerSyntheticFrontEnd
BlockPointerSyntheticFrontEnd does a CopyType which results in it copying the type back into its own context. This will result in a call to ASTImporterDelegate::setOrigin with &decl->getASTContext() == origin.ctx this can result in an infinite recursion later on in ASTImporter since it will attempt to find the decl in its origin which will be itself.
Differential Revision: https://reviews.llvm.org/D96366
show more ...
|
|
Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2 |
|
| #
839e8452 |
| 10-Dec-2020 |
Raphael Isemann <[email protected]> |
[lldb] Remove assumption from Clang-based data formatters that their types are in the scratch AST
Several data formatters assume their types are in the Target's scratch AST and build new types from
[lldb] Remove assumption from Clang-based data formatters that their types are in the scratch AST
Several data formatters assume their types are in the Target's scratch AST and build new types from that scratch AST instance. However, types from different ASTs shouldn't be mixed, so this (unchecked) assumption may lead to problems if we ever have more than one scratch AST or someone somehow invokes data formatters on a type that are not in the scratch AST.
Instead we can use in all the formatters just the TypeSystem of the type we're formatting. That's much simpler and avoids all the headache of finding the right TypeSystem that matches the one of the formatted type.
Right now LLDB only has one scratch TypeSystemClang instance and we format only types that are in the scratch AST, so this doesn't change anything in the current way LLDB works. The intention here is to allow follow up refactorings that introduce multiple scratch ASTs with the same Target.
Differential Revision: https://reviews.llvm.org/D92757
show more ...
|
|
Revision tags: llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2 |
|
| #
7c9ebdd3 |
| 03-Feb-2020 |
Alex Langford <[email protected]> |
[lldb] Remove clang classes from lldb-forward.h
Summary: lldb-forward.h is convenient in many ways, but having clang-based class forward declarations in there makes it easy to proliferate uses of cl
[lldb] Remove clang classes from lldb-forward.h
Summary: lldb-forward.h is convenient in many ways, but having clang-based class forward declarations in there makes it easy to proliferate uses of clang outside of plugins. Removing them makes you much more conscious of when you're using something from clang and marks where we're using things from clang in non-plugins.
Differential Revision: https://reviews.llvm.org/D73935
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc1 |
|
| #
8be30215 |
| 29-Jan-2020 |
Alex Langford <[email protected]> |
[lldb] Move clang-based files out of Symbol
Summary: This change represents the move of ClangASTImporter, ClangASTMetadata, ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and TypeSyst
[lldb] Move clang-based files out of Symbol
Summary: This change represents the move of ClangASTImporter, ClangASTMetadata, ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h
This explicitly removes knowledge of clang internals from lldbSymbol, moving towards a more generic core implementation of lldb.
Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik
Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73661
show more ...
|
| #
c4f6fbe9 |
| 23-Jan-2020 |
Alex Langford <[email protected]> |
[lldb] Remove ClangASTImporter from Target
Target is one of the classes responsible for vending ClangASTImporter. Target doesn't need to know anything about ClangASTImporter, so if we instead have C
[lldb] Remove ClangASTImporter from Target
Target is one of the classes responsible for vending ClangASTImporter. Target doesn't need to know anything about ClangASTImporter, so if we instead have ClangPersistentVariables vend it, we can preserve existing behavior while improving layering and removing dependencies from non-plugins to plugins.
show more ...
|
| #
80814287 |
| 24-Jan-2020 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp ----------------------------------------
[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
show more ...
|
| #
6e3b0cc2 |
| 23-Jan-2020 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary: This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do (implement the Type
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary: This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do (implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a `clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
show more ...
|
|
Revision tags: llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2 |
|
| #
0e252e38 |
| 30-Jul-2019 |
Alex Langford <[email protected]> |
[Symbol] Use llvm::Expected when getting TypeSystems
Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This mea
[Symbol] Use llvm::Expected when getting TypeSystems
Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem.
Reviewers: JDevlieghere, davide, compnerd
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D65122
llvm-svn: 367360
show more ...
|
|
Revision tags: llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4 |
|
| #
0e4c4821 |
| 06-Mar-2019 |
Adrian Prantl <[email protected]> |
Pass ConstString by value (NFC)
My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed.
ConstString has exactly one const char * data member, s
Pass ConstString by value (NFC)
My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed.
ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object.
(This fixes rdar://problem/48640859 for the Apple folks)
Differential Revision: https://reviews.llvm.org/D59030
llvm-svn: 355553
show more ...
|
|
Revision tags: llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
| #
ceff6644 |
| 11-Nov-2018 |
Jonas Devlieghere <[email protected]> |
Remove header grouping comments.
This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdate
Remove header grouping comments.
This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain.
llvm-svn: 346626
show more ...
|
| #
eca07c59 |
| 05-Nov-2018 |
Adrian Prantl <[email protected]> |
Fix (and improve) the support for C99 variable length array types
Clang recently improved its DWARF support for C VLA types. The DWARF now looks like this:
0x00000051: DW_TAG_variable [4]
Fix (and improve) the support for C99 variable length array types
Clang recently improved its DWARF support for C VLA types. The DWARF now looks like this:
0x00000051: DW_TAG_variable [4] DW_AT_location( fbreg -32 ) DW_AT_name( "__vla_expr" ) DW_AT_type( {0x000000d3} ( long unsigned int ) ) DW_AT_artificial( true ) ... 0x000000da: DW_TAG_array_type [10] * DW_AT_type( {0x000000cc} ( int ) )
0x000000df: DW_TAG_subrange_type [11] DW_AT_type( {0x000000e9} ( __ARRAY_SIZE_TYPE__ ) ) DW_AT_count( {0x00000051} )
Without this patch LLDB will naively interpret the DIE offset 0x51 as the static size of the array, which is clearly wrong. This patch extends ValueObject::GetNumChildren to query the dynamic properties of incomplete array types.
See the testcase for an example:
4 int foo(int a) { 5 int vla[a]; 6 for (int i = 0; i < a; ++i) 7 vla[i] = i; 8 -> 9 pause(); // break here 10 return vla[a-1]; 11 }
(lldb) fr v vla (int []) vla = ([0] = 0, [1] = 1, [2] = 2, [3] = 3) (lldb) quit
rdar://problem/21814005
Differential Revision: https://reviews.llvm.org/D53530
llvm-svn: 346165
show more ...
|
|
Revision tags: llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2 |
|
| #
05097246 |
| 30-Apr-2018 |
Adrian Prantl <[email protected]> |
Reflow paragraphs in comments.
This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to r
Reflow paragraphs in comments.
This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue
if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2)
continue
if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
show more ...
|
|
Revision tags: llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2 |
|
| #
97206d57 |
| 12-May-2017 |
Zachary Turner <[email protected]> |
Rename Error -> Status.
This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without find and replace, but that h
Rename Error -> Status.
This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious.
llvm-svn: 302872
show more ...
|
|
Revision tags: llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
| #
b9c1b51e |
| 06-Sep-2016 |
Kate Stone <[email protected]> |
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications:
Firstly, merging t
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
show more ...
|
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1 |
|
| #
c530ba98 |
| 02-May-2016 |
Sean Callanan <[email protected]> |
Import block pointers from DWARF as Clang block pointers, not as structs.
Also added a data formatter that presents them as structs if you use frame variable to look at their contents. Now the bloc
Import block pointers from DWARF as Clang block pointers, not as structs.
Also added a data formatter that presents them as structs if you use frame variable to look at their contents. Now the blocks testcase works.
<rdar://problem/15984431>
llvm-svn: 268307
show more ...
|