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
Summary:
When we want to compare a ConstString against a string literal (or any other non-ConstString),
we currently have to explicitly turn the other string into a ConstString. This makes sense as
comparing ConstStrings against each other is only a fast pointer comparison.
However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when
we just want to compare a given ConstString against a hardcoded value, for example like this:
```
if (extension != ConstString(".oat") && extension != ConstString(".odex"))
```
Obviously this kind of defeats the point of ConstStrings. In the comparison above we would
construct two temporary ConstStrings every time we hit the given code. Constructing a
ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly
an exclusive write-lock and then look up our temporary string in the string map of the pool.
So we do a lot of heavy work for essentially just comparing a <6 characters in two strings.
I initially wanted to just fix these issues by turning the temporary ConstString in static variables/
members, but that made the code much less readable. Instead I propose to add a new overload
for the ConstString comparison operator that takes a StringRef. This comparison operator directly
compares the ConstString content against the given StringRef without turning the StringRef into
a ConstString.
This means that the example above can look like this now:
```
if (extension != ".oat" && extension != ".odex")
```
It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing
the temporary ConstString instances. Instead this should end up just being a direct string comparison
of the two given strings on most compilers.
This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new
comparison operator. It also adds a some unit tests for the new and old comparison operator.
Reviewers: #lldb, JDevlieghere, espindola, amccarth
Reviewed By: JDevlieghere, amccarth
Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60667
llvm-svn: 359281
Summary:
This previous fix 5469bda296 did not have a test since we did not have a reproducer.
This is related to how formatters deal with pointers and references. The added tests both the new behavior and covers the previous bug fix as well.
Differential Revision: https://reviews.llvm.org/D60588
llvm-svn: 359118
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
There's a single report of a crash coming from this current_sp being NULL. I don't
have a repro case, and I couldn't get it to happen by hand-corrupting a list. We
always get an error instead. So I don't have a test case. But checking for null
is clearly right here.
<rdar://problem/48503320>
llvm-svn: 355957
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
In r353906 we hooked up clang and lldb's reproducer infrastructure to
capture files used by clang. This patch adds the necessary logic to have
clang reuse the files from lldb's reproducer during replay.
Differential revision: https://reviews.llvm.org/D58309
llvm-svn: 354283
Type punning through a union -> no good.
double to uint64 to double again -> no good either.
The nice side effect, other than silencing the sanitizer bot
is that it fixes the formatting of some dates, e.g. Jan 1st 1970.
<rdar://problem/47617983>
llvm-svn: 353191
libc++ has programmable ABI versioning controllable with the _LIBCPP_ABI_VERSION
macro. Currently there are at least 3 settings used in real systems (1 as the
default, ndk1 for Anroid, Cr for Chromium).
Only the 1 and ndk1 cases were handled. This change relaxes the check to allow
any ABI version.
Differential Revision: https://reviews.llvm.org/D57466
llvm-svn: 352899
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
The code in LLDB assumes that CompilerType and friends use the size 0
as a sentinel value to signal an error. This works for C++, where no
zero-sized type exists, but in many other programming languages
(including I believe C) types of size zero are possible and even
common. This is a particular pain point in swift-lldb, where extra
code exists to double-check that a type is *really* of size zero and
not an error at various locations.
To remedy this situation, this patch starts by converting
CompilerType::getBitSize() and getByteSize() to return an optional
result. To avoid wasting space, I hand-rolled my own optional data
type assuming that no type is larger than what fits into 63
bits. Follow-up patches would make similar changes to the ValueObject
hierarchy.
rdar://problem/47178964
Differential Revision: https://reviews.llvm.org/D56688
llvm-svn: 351214
This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:
run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD
Differential revision: https://reviews.llvm.org/D55584
llvm-svn: 349215
This fixes two compilation failures:
1) Designated initializers are C++20. We can't use them in LLVM.
2) thread_result_t is not a pointer type on all platforms, so
returning nullptr is an error.
llvm-svn: 346873
error: implicit conversion from 'double' to 'uint64_t' (aka 'unsigned long') changes value from -0 to 0 [-Werror,-Wliteral-conversion]
llvm-svn: 346841
An Obj-C array type _NSCallStackArray is used in NSException backtraces. This patch adds a synthetic frontend for _NSCallStackArray, which now correctly returns frame PCs.
Differential Revision: https://reviews.llvm.org/D44081
llvm-svn: 346708
This patch teaches LLDB about more fields on NSException Obj-C objects, specifically we can now retrieve the "name" and "reason" of an NSException. The goal is to eventually be able to have SB API that can provide details about the currently thrown/caught/processed exception.
Differential Revision: https://reviews.llvm.org/D43884
llvm-svn: 346695
- Refactor reading of NSException fields into ExtractFields method to avoid code duplication.
- Remove "m_child_ptr" field, as it's not used anywhere.
- Clang-format.
Differential Revision: https://reviews.llvm.org/D44073
llvm-svn: 346679
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
Summary:
Now that llvm demangler supports more generic customization, we can
implement type substitution directly on top of this API. This will allow
us to remove the specialized hooks which were added to the demangler to
support this use case.
Reviewers: sgraenitz, erik.pilkington, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D54074
llvm-svn: 346233
This patch introduces the simple MSVCUndecoratedNameParser. It is needed for
parsing names of PDB symbols corresponding to template instantiations. For
example, for the name `operator<<A>'::`2'::B::operator> we can't just split the
name with :: (as it is implemented for now) to retrieve its scopes. This parser
processes such names in a more correct way.
Differential Revision: https://reviews.llvm.org/D52461
llvm-svn: 346213
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
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.
This patch removes the OCaml debugger plugin.
The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html
Differential revision: https://reviews.llvm.org/D54060
llvm-svn: 346159
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.
This patch removes the Java debugger plugin.
The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html
Differential revision: https://reviews.llvm.org/D54059
llvm-svn: 346158
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.
This patch removes the Go debugger plugin.
The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html
Differential revision: https://reviews.llvm.org/D54057
llvm-svn: 346157
We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.
Differential revision: https://reviews.llvm.org/D53547
llvm-svn: 345637
Summary:
The syntax highlighting feature so far is mutually exclusive with the lldb feature
that marks the current column in the line by underlining it via an ANSI color code.
Meaning that if you enable one, the other is automatically disabled by LLDB.
This was caused by the fact that both features inserted color codes into the the
source code and were likely to interfere with each other (which would result
in a broken source code printout to the user).
This patch moves the cursor code into the highlighting framework, which provides
the same feature to the user in normal non-C source code. For any source code
that is highlighted by Clang, we now also have cursor marking for the whole token
that is under the current source location. E.g., before we underlined only the '!' in the
expression '1 != 2', but now the whole token '!=' is underlined. The same for function
calls and so on. Below you can see two examples where we before only underlined
the first character of the token, but now underline the whole token.
{F7075400}
{F7075414}
It also simplifies the DisplaySourceLines method in the SourceManager as most of
the code in there was essentially just for getting this column marker to work as
a FormatEntity.
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D51466
llvm-svn: 341003
- Added LibcxxFunctionSummaryProvider
- Removed LibcxxFunctionFrontEnd
- Modified data formatter tests to test new summary functionality
Patch by Shafik Yaghmour!
Differential Revision: https://reviews.llvm.org/D50864
llvm-svn: 340543
Patch by Shafik Yaghmour!
This reapplies an earlier version after addressing some post-commit feedback.
Differential Revision: https://reviews.llvm.org/D49271
llvm-svn: 339828
Summary:
This removes the manual byte counting mechanism from the syntax highlighting
code. This is no longer necessary as the Stream class now has built-in support for
automatically counting the bytes that were written to it so far.
The advantage of automatic byte counting via Stream is that it is less error-prone
than the manual version and we need to write less boilerplate code.
Reviewers: labath
Reviewed By: labath
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D50676
llvm-svn: 339695
