Summary:
According to [C128] "Virtual functions should specify exactly one
of `virtual`, `override`, or `final`", I've added override where a
virtual function is overriden but the explicit `override` keyword
was missing. Whenever both `virtual` and `override` were specified,
I removed `virtual`. As C.128 puts it:
> [...] writing more than one of these three is both redundant and
> a potential source of errors.
I anticipate a discussion about whether or not to add `override` to
destructors but I went for it because of an example in [ISOCPP1000].
Let me repeat the comment for you here:
Consider this code:
```
struct Base {
virtual ~Base(){}
};
struct SubClass : Base {
~SubClass() {
std::cout << "It works!\n";
}
};
int main() {
std::unique_ptr<Base> ptr = std::make_unique<SubClass>();
}
```
If for some odd reason somebody removes the `virtual` keyword from the
`Base` struct, the code will no longer print `It works!`. So adding
`override` to destructors actively protects us from accidentally
breaking our code at runtime.
[C128]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c128-virtual-functions-should-specify-exactly-one-of-virtual-override-or-final
[ISOCPP1000]: https://github.com/isocpp/CppCoreGuidelines/issues/1000#issuecomment-476951555
Reviewers: teemperor, JDevlieghere, davide, shafik
Reviewed By: teemperor
Subscribers: kwk, arphaman, kadircet, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61440
llvm-svn: 359868
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
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
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
This brings the LLDB configuration closer to LLVM's and removes visual
clutter in the source code by removing the @brief commands from
comments.
This patch also reflows the paragraphs in all doxygen comments.
See also https://reviews.llvm.org/D46290.
Differential Revision: https://reviews.llvm.org/D46321
llvm-svn: 331373
Summary:
r316368 broke this build when it introduced a reference to a pthread
function to the Utility module. This caused cmake to generate an
incorrect link line (wrong order of libs) because it did not see the
dependency from Utility to the system libraries. Instead these libraries
were being manually added to each final target.
This changes moves the dependency management from the individual targets
to the lldbUtility module, which is consistent with how llvm does it.
The final targets will pick up these libraries as they will be a part of
the link interface of the module.
Technically, some of these dependencies could go into the host module,
as that's where most of the os-specific code is, but I did not try to
investigate which ones.
Reviewers: zturner, sylvestre.ledru
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D39246
llvm-svn: 316997
-- 2 files were missing in this commit which should have been there.
These files were submitted initially for review and were reviewed.
However, while updating the revision with newer diffs, I accidentally
forgot to include them in newer diffs. So commiting now.
llvm-svn: 310341
Summary:
1. Provide single library for all Intel specific hardware features instead
of individual libraries for each feature
2. Added Intel(R) Processor Trace hardware feature in this single library.
Details about the tool implementing this feature is as follows:
Tool developed on top of LLDB to provide its users the execution
trace of the debugged inferiors. Tool's API are exposed as C++ object
oriented interface in a shared library. API are designed especially to be
easily integrable with IDEs providing LLDB as an application debugger.
Entire API is also available as Python functions through a script bridging
interface allowing development of python modules.
This patch also provides a CLI wrapper to use the Tool through LLDB's command
line. Highlights of the Tool and the wrapper are given below:
******************************
Intel(R) Processor Trace Tool:
******************************
- Provides execution trace of the debugged application
- Uses Intel(R) Processor Trace hardware feature (already implemented inside LLDB)
for this purpose
-- Collects trace packets generated by this feature from LLDB, decodes and
post-processes them
-- Constructs the execution trace of the application
-- Presents execution trace as a list of assembly instructions
- Provides 4 APIs (exposed as C++ object oriented interface)
-- start trace with configuration options for a thread/process,
-- stop trace for a thread/process,
-- get the execution flow (assembly instructions) for a thread,
-- get trace specific information for a thread
- Easily integrable into IDEs providing LLDB as application debugger
- Entire API available as Python functions through script bridging interface
-- Allows developing python apps on top of Tool
- README_TOOL.txt provides more details about the Tool, its dependencies, building
steps and API usage
- Tool ready to use through LLDB's command line
-- CLI wrapper has been developed on top of the Tool for this purpose
*********************************
CLI wrapper: cli-wrapper-pt.cpp
*********************************
- Provides 4 commands (syntax similar to LLDB's CLI commands):
-- processor-trace start
-- processor-trace stop
-- processor-trace show-trace-options
-- processor-trace show-instr-log
- README_CLI.txt provides more details about commands and their options
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: clayborg, jingham, lldb-commits, labath
Reviewed By: clayborg
Subscribers: ravitheja, emaste, krytarowski, mgorny
Differential Revision: https://reviews.llvm.org/D33035
llvm-svn: 310261
Fangrui Song