<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/Commands/CommandObjectHelp.h, branch users/mingmingl-llvm/samplefdo-profile-format</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] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` return `void` (not `bool`) (#69991)</title>
<updated>2023-10-30T20:21:00+00:00</updated>
<author>
<name>Pete Lawrence</name>
<email>plawrence@apple.com</email>
</author>
<published>2023-10-30T20:21:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=92d8a28cc665d73d9d679b8c014dd04f95d1df18'/>
<id>92d8a28cc665d73d9d679b8c014dd04f95d1df18</id>
<content type='text'>
[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` to return
`void` instead of ~~`bool`~~

Justifications:
- The code doesn't ultimately apply the `true`/`false` return values.
- The methods already pass around a `CommandReturnObject`, typically
with a `result` parameter.
- Each command return object already contains:
	- A more precise status
	- The error code(s) that apply to that status

Part 1 refactors the `CommandObject::Execute(...)` method.
- See
[https://github.com/llvm/llvm-project/pull/69989](https://github.com/llvm/llvm-project/pull/69989)

rdar://117378957</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` to return
`void` instead of ~~`bool`~~

Justifications:
- The code doesn't ultimately apply the `true`/`false` return values.
- The methods already pass around a `CommandReturnObject`, typically
with a `result` parameter.
- Each command return object already contains:
	- A more precise status
	- The error code(s) that apply to that status

Part 1 refactors the `CommandObject::Execute(...)` method.
- See
[https://github.com/llvm/llvm-project/pull/69989](https://github.com/llvm/llvm-project/pull/69989)

rdar://117378957</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Fix modernize-use-equals-default warnings (NFC)</title>
<updated>2022-06-17T22:08:02+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2022-06-17T22:03:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=91688716ba49942051dccdf7b9c4f81a7ec8feaf'/>
<id>91688716ba49942051dccdf7b9c4f81a7ec8feaf</id>
<content type='text'>
Fix modernize-use-equals-default warnings. Because this check is listed
in LLDB's top level .clang-tidy configuration, the check is enabled by
default and the resulting warnings show up in my editor.

I've audited the modified lines. This is not a blind change.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix modernize-use-equals-default warnings. Because this check is listed
in LLDB's top level .clang-tidy configuration, the check is enabled by
default and the resulting warnings show up in my editor.

I've audited the modified lines. This is not a blind change.
</pre>
</div>
</content>
</entry>
<entry>
<title>[Commands] Remove redundant member initialization (NFC)</title>
<updated>2022-01-23T19:07:14+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2022-01-23T19:07:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=abb0ed44957cb4ba1bc94d19202860f10369cea1'/>
<id>abb0ed44957cb4ba1bc94d19202860f10369cea1</id>
<content type='text'>
Identified with readability-redundant-member-init.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Identified with readability-redundant-member-init.
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Replace default bodies of special member functions with = default;</title>
<updated>2021-07-02T18:31:16+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2021-07-02T18:27:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=fd2433e139f78658e059cf911af8ae735fcda57c'/>
<id>fd2433e139f78658e059cf911af8ae735fcda57c</id>
<content type='text'>
Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

Differential revision: https://reviews.llvm.org/D104041
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

Differential revision: https://reviews.llvm.org/D104041
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Update header guards to be consistent and compliant with LLVM (NFC)</title>
<updated>2020-02-18T07:15:40+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2020-02-17T23:57:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cdc514e4c67f268b07863bbac3d8d7e0d088186c'/>
<id>cdc514e4c67f268b07863bbac3d8d7e0d088186c</id>
<content type='text'>
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.

Differential revision: https://reviews.llvm.org/D74743
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.

Differential revision: https://reviews.llvm.org/D74743
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][NFC] Remove dead code that is supposed to handle invalid command options</title>
<updated>2019-08-22T08:08:05+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2019-08-22T08:08:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=36162014c4697c30af588197d7cdeb8d2930abbf'/>
<id>36162014c4697c30af588197d7cdeb8d2930abbf</id>
<content type='text'>
Summary:
We currently have a bunch of code that is supposed to handle invalid command options, but
all this code is unreachable because invalid options are already handled in `Options::Parse`.
The only way we can reach this code is when we declare but then not implement an option
(which will be made impossible with D65386, which is also when we can completely remove
the `default` cases).

This patch replaces all this code with `llvm_unreachable` to make clear this is dead code
that can't be reached.

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D66522

llvm-svn: 369625
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
We currently have a bunch of code that is supposed to handle invalid command options, but
all this code is unreachable because invalid options are already handled in `Options::Parse`.
The only way we can reach this code is when we declare but then not implement an option
(which will be made impossible with D65386, which is also when we can completely remove
the `default` cases).

This patch replaces all this code with `llvm_unreachable` to make clear this is dead code
that can't be reached.

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D66522

llvm-svn: 369625
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values</title>
<updated>2019-08-22T07:41:23+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2019-08-22T07:41:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ae34ed2c0d2fba36d8363ba7fffc1dbe18878335'/>
<id>ae34ed2c0d2fba36d8363ba7fffc1dbe18878335</id>
<content type='text'>
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:

* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.

I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.

A few words why those things should be removed/replaced:

* The return values are really cryptic, partly redundant and rarely documented.
  They are also completely ignored by Xcode, so whatever information they contain will end up
  breaking Xcode's completion mechanism. They are also partly impossible to even implement
  as we assign negative values special meaning and our completion API sometimes returns size_t.

  Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
  in some untested code path to expand the history repeat character to the full command, but
  I haven't figured out why that doesn't work at the moment.
  Completion functions return -1 to 'insert the completion character', but that isn't implemented
  (even though we seem to activate this feature in LLDB sometimes).
  All positive values have to match the number of results. This is obviously just redundant information
  as the user can just look at the result list to get that information (which is what Xcode does).

* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
  reserved for the common prefix of all completions (e.g. "foobar" and "footar" -&gt; "foo"). The idea is
  that we calculate this to make the life of the API caller easier, but obviously forcing people to have
  1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
  0-based like Xcode has to do).

* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
  idea is that we let the top-level API know that we just provided a full completion. Interestingly we
  `WordComplete` is just a single bool that somehow represents all N completions. And we always
  provide full completions in LLDB, so in theory it should always be true.
  The only use it currently serves is providing redundant information about whether we have a single
  definitive completion or not (which we already know from the number of results we get).

This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.

For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).

I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: arphaman, abidh, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D66536

llvm-svn: 369624
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:

* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.

I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.

A few words why those things should be removed/replaced:

* The return values are really cryptic, partly redundant and rarely documented.
  They are also completely ignored by Xcode, so whatever information they contain will end up
  breaking Xcode's completion mechanism. They are also partly impossible to even implement
  as we assign negative values special meaning and our completion API sometimes returns size_t.

  Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
  in some untested code path to expand the history repeat character to the full command, but
  I haven't figured out why that doesn't work at the moment.
  Completion functions return -1 to 'insert the completion character', but that isn't implemented
  (even though we seem to activate this feature in LLDB sometimes).
  All positive values have to match the number of results. This is obviously just redundant information
  as the user can just look at the result list to get that information (which is what Xcode does).

* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
  reserved for the common prefix of all completions (e.g. "foobar" and "footar" -&gt; "foo"). The idea is
  that we calculate this to make the life of the API caller easier, but obviously forcing people to have
  1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
  0-based like Xcode has to do).

* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
  idea is that we let the top-level API know that we just provided a full completion. Interestingly we
  `WordComplete` is just a single bool that somehow represents all N completions. And we always
  provide full completions in LLDB, so in theory it should always be true.
  The only use it currently serves is providing redundant information about whether we have a single
  definitive completion or not (which we already know from the number of results we get).

This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.

For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).

I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: arphaman, abidh, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D66536

llvm-svn: 369624
</pre>
</div>
</content>
</entry>
<entry>
<title>[NFC] Remove ASCII lines from comments</title>
<updated>2019-04-10T20:48:55+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2019-04-10T20:48:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=8b3af63b8993e45b1783853a3fcf6f36bfbed81b'/>
<id>8b3af63b8993e45b1783853a3fcf6f36bfbed81b</id>
<content type='text'>
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

Differential revision: https://reviews.llvm.org/D60508

llvm-svn: 358135
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

Differential revision: https://reviews.llvm.org/D60508

llvm-svn: 358135
</pre>
</div>
</content>
</entry>
<entry>
<title>Replace 'ap' with 'up' suffix in variable names. (NFC)</title>
<updated>2019-02-13T06:25:41+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2019-02-13T06:25:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d5b440369dbb0d41e6ecd47d6ac7410201e27f17'/>
<id>d5b440369dbb0d41e6ecd47d6ac7410201e27f17</id>
<content type='text'>
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.

In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.

I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.

llvm-svn: 353912
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.

In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.

I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.

llvm-svn: 353912
</pre>
</div>
</content>
</entry>
<entry>
<title>Update the file headers across all of the LLVM projects in the monorepo</title>
<updated>2019-01-19T08:50:56+00:00</updated>
<author>
<name>Chandler Carruth</name>
<email>chandlerc@gmail.com</email>
</author>
<published>2019-01-19T08:50:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2946cd701067404b99c39fb29dc9c74bd7193eb3'/>
<id>2946cd701067404b99c39fb29dc9c74bd7193eb3</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
</feed>
