| Age | Commit message (Collapse) | Author |
|---|
|
From
https://github.com/llvm/llvm-project/pull/163077#issuecomment-3396435083:
Currently, `std::atomic<T>` will always use the MSVC STL synthetic
children and summary. When inspecting types from other STLs, the output
would not show any children.
This PR adds a check that `std::atomic` contains `_Storage` to be
classified as coming from MSVC's STL.
|
|
This patch replaces the use of `UINT32_MAX` as the error return value of
`GetIndexOfChildWithName` with `llvm::Expected`.
# Tasks to do in another PR
1. Replace `CalculateNumChildrenIgnoringErrors` with
`CalculateNumChildren`. See [this
comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056319358).
2. Update `lldb_private::formatters::ExtractIndexFromString` to use
`llvm::Expected`. See [this
comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2054217536).
3. Create a new class which carries both user and internal errors. See
[this
comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056439608).
|
|
The vast majority of `SyntheticChildrenFrontEnd` subclasses provide
children, and as such implement `MightHaveChildren` with a constant
value of `true`. This change makes `true` the default value. With this
change, `MightHaveChildren` only needs to be implemented by synthetic
providers that can return `false`, which is only 3 subclasses.
|
|
(#84219)
Change GetNumChildren()/CalculateNumChildren() methods return
llvm::Expected
This is an NFC change that does not yet add any error handling or change
any code to return any errors.
This is the second big change in the patch series started with
https://github.com/llvm/llvm-project/pull/83501
A follow-up PR will wire up error handling.
|
|
llvm::Expected (#84219)"
This reverts commit 99118c809367d518ffe4de60c16da953744b68b9.
|
|
(#84219)
Change GetNumChildren()/CalculateNumChildren() methods return
llvm::Expected
This is an NFC change that does not yet add any error handling or change
any code to return any errors.
This is the second big change in the patch series started with
https://github.com/llvm/llvm-project/pull/83501
A follow-up PR will wire up error handling.
|
|
|
|
This way it is consistent with ValueObject and TypeSystem.
|
|
an enum (#80167)
This patch changes the return value of
`SyntheticChildrenFrontend::Update` to a scoped enum that aims to
describe what the return value means.
|
|
It turns out all existing callers of `GetChildMemberWithName` pass true for `can_create`.
This change makes `true` the default value, callers don't have to pass an opaque true.
Differential Revision: https://reviews.llvm.org/D151966
|
|
`GetChildMemberWithName` does not need a `ConstString`. This change makes the function
take a `StringRef` instead, which alleviates the need for callers to construct a
`ConstString`. I don't expect this change to improve performance, only ergonomics.
This is in support of Alex's effort to replace `ConstString` where appropriate.
There are related `ValueObject` functions that can also be changed, if this is accepted.
Differential Revision: https://reviews.llvm.org/D151615
|
|
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D140623
|
|
Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in class member init but
never updated the constructors to reflect that. This check is already present in
the lldb/.clang-tidy config.
Differential Revision: https://reviews.llvm.org/D121481
|
|
formatter
Summary:
Currently the data formatter is treating `std::atomic` variables as transparent wrappers
around their underlying value type. This causes that when printing `std::atomic<A *>`, the data
formatter will forward all requests for the children of the atomic variable to the `A *` pointer type
which will then return the respective members of `A`. If `A` in turn has a member that contains
the original atomic variable, this causes LLDB to infinitely recurse when printing an object with
such a `std::atomic` pointer member.
We could implement a workaround similar to whatever we do for pointer values but this patch
just implements the `std::atomic` formatter in the same way as we already implement other
formatters (e.g. smart pointers or `std::optional`) that just model the contents of the as a child
"Value". This way LLDB knows when it actually prints a pointer and can just use its normal
workaround if "Value" is a recursive pointer.
Fixes rdar://59189235
Reviewers: JDevlieghere, jingham, shafik
Reviewed By: shafik
Subscribers: shafik, christof, jfb, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74310
|
|
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
|
|
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
|
|
https://reviews.llvm.org/D56913
rdar://problem/48568543
llvm-svn: 355422
|
|
caused by https://reviews.llvm.org/D56913"
This reverts commit r355351.
llvm-svn: 355352
|
|
https://reviews.llvm.org/D56913
rdar://problem/48568543
llvm-svn: 355351
|
|
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
|
|
*** 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
|
|
llvm-svn: 260761
|
|
On libc++ std::atomic is a fairly simple data type (layout wise, at least), wrapping actual contents in a member variable named "__a_"
All the formatters are doing is "peel away" this intermediate layer and exposing user data as direct children or values of the std::atomic root variable
Fixes rdar://24329405
llvm-svn: 260752
|
