<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/Commands/CommandObjectFrame.cpp, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[lldb] When starting in a hidden frame, don't skip over hidden frames when navigating up/down (#166394)</title>
<updated>2025-11-04T16:24:24+00:00</updated>
<author>
<name>Michael Buch</name>
<email>michaelbuch12@gmail.com</email>
</author>
<published>2025-11-04T16:24:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4749bf56a65e38ee7b05ac7f9fe261aab6cb5bc6'/>
<id>4749bf56a65e38ee7b05ac7f9fe261aab6cb5bc6</id>
<content type='text'>
When stopped in a hidden frame (either because we selected the hidden
frame or hit a breakpoint inside it), a user most likely is intersted in
exploring the immediate frames around it. But currently issuing
`up`/`down` commands will unconditionally skip over all hidden frames.

This patch makes it so `up`/`down` commands don't skip hidden frames if
the frame we started it was a hidden frame.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When stopped in a hidden frame (either because we selected the hidden
frame or hit a breakpoint inside it), a user most likely is intersted in
exploring the immediate frames around it. But currently issuing
`up`/`down` commands will unconditionally skip over all hidden frames.

This patch makes it so `up`/`down` commands don't skip hidden frames if
the frame we started it was a hidden frame.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Correct style of error messages (#156774)</title>
<updated>2025-09-04T23:37:41+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-09-04T23:37:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=820f4402745dda82fca482f2b83925e2953e6ad9'/>
<id>820f4402745dda82fca482f2b83925e2953e6ad9</id>
<content type='text'>
The LLVM Style Guide says the following about error and warning messages
[1]:

&gt; [T]o match error message styles commonly produced by other tools,
&gt; start the first sentence with a lowercase letter, and finish the last
&gt; sentence without a period, if it would end in one otherwise.

I often provide this feedback during code review, but we still have a
bunch of places where we have inconsistent error message, which bothers
me as a user. This PR identifies a handful of those places and updates
the messages to be consistent.

[1] https://llvm.org/docs/CodingStandards.html#error-and-warning-messages</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The LLVM Style Guide says the following about error and warning messages
[1]:

&gt; [T]o match error message styles commonly produced by other tools,
&gt; start the first sentence with a lowercase letter, and finish the last
&gt; sentence without a period, if it would end in one otherwise.

I often provide this feedback during code review, but we still have a
bunch of places where we have inconsistent error message, which bothers
me as a user. This PR identifies a handful of those places and updates
the messages to be consistent.

[1] https://llvm.org/docs/CodingStandards.html#error-and-warning-messages</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Underline short option letters as mnemonics (#153695)</title>
<updated>2025-08-26T15:07:24+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-08-26T15:07:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=26777283e6cb952ba9242c6299b0948dcc3253a5'/>
<id>26777283e6cb952ba9242c6299b0948dcc3253a5</id>
<content type='text'>
Whenever an option would use something other than the first letter of
the long option as the short option, Jim would capitalized the letter we
picked as a mnemonic. This has often been mistaken for a typo and Jim
wondered if we should stop doing this.

During the discussion, David mentioned how this reminds him of the
underline in menu bars when holding down alt. I suggested we do
something similar in LLDB by underlying the letter in the description.

https://discourse.llvm.org/t/should-we-remove-the-capital-letter-in-option-helps/87816</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Whenever an option would use something other than the first letter of
the long option as the short option, Jim would capitalized the letter we
picked as a mnemonic. This has often been mistaken for a typo and Jim
wondered if we should stop doing this.

During the discussion, David mentioned how this reminds him of the
underline in menu bars when holding down alt. I suggested we do
something similar in LLDB by underlying the letter in the description.

https://discourse.llvm.org/t/should-we-remove-the-capital-letter-in-option-helps/87816</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Use std::make_shared where possible (NFC) (#150714)</title>
<updated>2025-07-25T22:55:21+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-07-25T22:55:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cf6a4bbc42c7e54bf6e251206134b207e757b604'/>
<id>cf6a4bbc42c7e54bf6e251206134b207e757b604</id>
<content type='text'>
This is a continuation of 68fd102, which did the same thing but only for
StopInfo. Using make_shared is both safer and more efficient:

- With make_shared, the object and the control block are allocated
  together, which is more efficient.
- With make_shared, the enable_shared_from_this base class is properly
  linked to the control block before the constructor finishes, so
  shared_from_this() will be safe to use (though still not recommended
  during construction).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a continuation of 68fd102, which did the same thing but only for
StopInfo. Using make_shared is both safer and more efficient:

- With make_shared, the object and the control block are allocated
  together, which is more efficient.
- With make_shared, the enable_shared_from_this base class is properly
  linked to the control block before the constructor finishes, so
  shared_from_this() will be safe to use (though still not recommended
  during construction).</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Store the return SBValueList in the CommandReturnObject (#127566)</title>
<updated>2025-02-19T23:17:35+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-02-19T23:17:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f62f13d5db212b4bebe6fc143fb9827703e88dfd'/>
<id>f62f13d5db212b4bebe6fc143fb9827703e88dfd</id>
<content type='text'>
There are a lot of lldb commands whose result is really one or more
ValueObjects that we then print with the ValueObjectPrinter. Now that we
have the ability to access the SBCommandReturnObject through a callback
(#125006), we can store the resultant ValueObjects in the return object,
allowing an IDE to access the SBValues and do its own rich formatting.

rdar://143965453</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are a lot of lldb commands whose result is really one or more
ValueObjects that we then print with the ValueObjectPrinter. Now that we
have the ability to access the SBCommandReturnObject through a callback
(#125006), we can store the resultant ValueObjects in the return object,
allowing an IDE to access the SBValues and do its own rich formatting.

rdar://143965453</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Move ValueObject into its own library (NFC) (#113393)</title>
<updated>2024-10-25T03:20:48+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2024-10-25T03:20:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b852fb1ec5fa15f0b913cc4988cbd09239b19904'/>
<id>b852fb1ec5fa15f0b913cc4988cbd09239b19904</id>
<content type='text'>
ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-time) circular
dependency between lldbCore and lldbValueObject, which is unfortunate
but probably unavoidable because so many things in LLDB rely on
ValueObject. We already have cycles and these libraries are never built
as dylibs so while this doesn't improve the situation, it also doesn't
make things worse.

The header includes were updated with the following command:

```
find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \;
```</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-time) circular
dependency between lldbCore and lldbValueObject, which is unfortunate
but probably unavoidable because so many things in LLDB rely on
ValueObject. We already have cycles and these libraries are never built
as dylibs so while this doesn't improve the situation, it also doesn't
make things worse.

The header includes were updated with the following command:

```
find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \;
```</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Fix typos in various help messages. (#109851)</title>
<updated>2024-09-24T23:48:27+00:00</updated>
<author>
<name>Ryan Mansfield</name>
<email>ryan_mansfield@apple.com</email>
</author>
<published>2024-09-24T23:48:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4494c54326fe33d19c14df851188f867b14ded2a'/>
<id>4494c54326fe33d19c14df851188f867b14ded2a</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Add support for disabling frame recognizers (#109219)</title>
<updated>2024-09-20T20:17:42+00:00</updated>
<author>
<name>Adrian Vogelsgesang</name>
<email>avogelsgesang@salesforce.com</email>
</author>
<published>2024-09-20T20:17:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d8d252fe96877f9fdbf6b0b6c19da543e796bb84'/>
<id>d8d252fe96877f9fdbf6b0b6c19da543e796bb84</id>
<content type='text'>
Sometimes you only want to temporarily disable a frame recognizer
instead of deleting it. In particular, when dealing with one of the
builtin frame recognizers, which cannot be restored after deletion.

To be able to write test cases for this functionality, I also changed
`lldb/test/API/commands/frame/recognizer` to use normal C instead of
Objective-C</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Sometimes you only want to temporarily disable a frame recognizer
instead of deleting it. In particular, when dealing with one of the
builtin frame recognizers, which cannot be restored after deletion.

To be able to write test cases for this functionality, I also changed
`lldb/test/API/commands/frame/recognizer` to use normal C instead of
Objective-C</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Turn lldb_private::Status into a value type. (#106163)</title>
<updated>2024-08-27T17:59:31+00:00</updated>
<author>
<name>Adrian Prantl</name>
<email>aprantl@apple.com</email>
</author>
<published>2024-08-27T17:59:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0642cd768b80665585c8500bed2933a3b99123dc'/>
<id>0642cd768b80665585c8500bed2933a3b99123dc</id>
<content type='text'>
This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

`    ResultTy DoFoo(Status&amp; error)
`
to

`    llvm::Expected&lt;ResultTy&gt; DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

`    ResultTy DoFoo(Status&amp; error)
`
to

`    llvm::Expected&lt;ResultTy&gt; DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Add frame recognizers for libc++ `std::invoke` (#105695)</title>
<updated>2024-08-27T17:15:42+00:00</updated>
<author>
<name>Adrian Vogelsgesang</name>
<email>avogelsgesang@salesforce.com</email>
</author>
<published>2024-08-27T17:15:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=dd060bdede8edec18ad5ca122e15cc24a821e3fe'/>
<id>dd060bdede8edec18ad5ca122e15cc24a821e3fe</id>
<content type='text'>
With this commit, we also hide the implementation details of
`std::invoke`. To do so, the `LibCXXFrameRecognizer` got a couple more
regular expressions.

The regular expression passed into `AddRecognizer` became problematic,
as it was evaluated on the demangled name. Those names also included
result types for C++ symbols. For `std::__invoke` the return type is a
huge `decltype(...)`, making the regular expresison really hard to
write.

Instead, I added support to `AddRecognizer` for matching on the
demangled names without result type and argument types.

By hiding the implementation details of `invoke`, also the back traces
for `std::function` become even nicer, because `std::function` is using
`__invoke` internally.

Co-authored-by: Adrian Prantl &lt;aprantl@apple.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With this commit, we also hide the implementation details of
`std::invoke`. To do so, the `LibCXXFrameRecognizer` got a couple more
regular expressions.

The regular expression passed into `AddRecognizer` became problematic,
as it was evaluated on the demangled name. Those names also included
result types for C++ symbols. For `std::__invoke` the return type is a
huge `decltype(...)`, making the regular expresison really hard to
write.

Instead, I added support to `AddRecognizer` for matching on the
demangled names without result type and argument types.

By hiding the implementation details of `invoke`, also the back traces
for `std::function` become even nicer, because `std::function` is using
`__invoke` internally.

Co-authored-by: Adrian Prantl &lt;aprantl@apple.com&gt;</pre>
</div>
</content>
</entry>
</feed>
