[lldb][NFC] Fix all formatting errors in .cpp file headers
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
2020-01-24 15:23:27 +08:00
|
|
|
//===-- RangeTest.cpp -----------------------------------------------------===//
|
RangeMap.h: merge RangeDataArray and RangeDataVector
Summary:
The main difference between the classes was supposed to be the fact that
one is backed by llvm::SmallVector, and the other by std::vector.
However, over the years, they have accumulated various other differences
too.
This essentially removes the std::vector version, as that is pretty much
identical to llvm::SmallVector<T, 0>, and combines their interfaces. It
does not attempt to do a more significant refactoring, even though there
is still a lot of duplication in this file, as it is hard to tell which
quirk of some API is depended on by somebody (and, a previous, more
ambitious attempt at this in D16769 has failed).
I also add some tests, including one which demonstrates one of the
quirks/bugs of the API I have noticed in the process.
Reviewers: clayborg, teemperor, tberghammer
Subscribers: mgorny, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56170
llvm-svn: 350380
2019-01-04 15:14:17 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
RangeMap.h: merge RangeDataArray and RangeDataVector
Summary:
The main difference between the classes was supposed to be the fact that
one is backed by llvm::SmallVector, and the other by std::vector.
However, over the years, they have accumulated various other differences
too.
This essentially removes the std::vector version, as that is pretty much
identical to llvm::SmallVector<T, 0>, and combines their interfaces. It
does not attempt to do a more significant refactoring, even though there
is still a lot of duplication in this file, as it is hard to tell which
quirk of some API is depended on by somebody (and, a previous, more
ambitious attempt at this in D16769 has failed).
I also add some tests, including one which demonstrates one of the
quirks/bugs of the API I have noticed in the process.
Reviewers: clayborg, teemperor, tberghammer
Subscribers: mgorny, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56170
llvm-svn: 350380
2019-01-04 15:14:17 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
Move RangeMap.h into Utility
Summary:
This file implements some general purpose data structures, and so it
belongs to the Utility module.
Reviewers: zturner, jingham, JDevlieghere, clayborg, espindola
Subscribers: emaste, mgorny, javed.absar, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D58970
llvm-svn: 355509
2019-03-06 22:41:43 +08:00
|
|
|
#include "lldb/Utility/RangeMap.h"
|
RangeMap.h: merge RangeDataArray and RangeDataVector
Summary:
The main difference between the classes was supposed to be the fact that
one is backed by llvm::SmallVector, and the other by std::vector.
However, over the years, they have accumulated various other differences
too.
This essentially removes the std::vector version, as that is pretty much
identical to llvm::SmallVector<T, 0>, and combines their interfaces. It
does not attempt to do a more significant refactoring, even though there
is still a lot of duplication in this file, as it is hard to tell which
quirk of some API is depended on by somebody (and, a previous, more
ambitious attempt at this in D16769 has failed).
I also add some tests, including one which demonstrates one of the
quirks/bugs of the API I have noticed in the process.
Reviewers: clayborg, teemperor, tberghammer
Subscribers: mgorny, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56170
llvm-svn: 350380
2019-01-04 15:14:17 +08:00
|
|
|
#include "gmock/gmock.h"
|
|
|
|
#include "gtest/gtest.h"
|
|
|
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
[lldb/Utility] Fix a bug in RangeMap::CombineConsecutiveRanges
The function didn't combine a large entry which overlapped several other
entries, if those other entries were not overlapping among each other.
E.g., (0,20),(5,6),(10,11) produced (0,20),(10,11)
Now it just produced (0,20).
2020-07-24 20:49:17 +08:00
|
|
|
TEST(RangeVector, CombineConsecutiveRanges) {
|
|
|
|
using RangeVector = RangeVector<uint32_t, uint32_t>;
|
|
|
|
using Entry = RangeVector::Entry;
|
|
|
|
|
|
|
|
RangeVector V;
|
|
|
|
V.Append(0, 1);
|
|
|
|
V.Append(5, 1);
|
|
|
|
V.Append(6, 1);
|
|
|
|
V.Append(10, 9);
|
|
|
|
V.Append(15, 1);
|
|
|
|
V.Append(20, 9);
|
|
|
|
V.Append(21, 9);
|
|
|
|
V.Sort();
|
|
|
|
V.CombineConsecutiveRanges();
|
|
|
|
EXPECT_THAT(V, testing::ElementsAre(Entry(0, 1), Entry(5, 2), Entry(10, 9),
|
|
|
|
Entry(20, 10)));
|
|
|
|
|
|
|
|
V.Clear();
|
|
|
|
V.Append(0, 20);
|
|
|
|
V.Append(5, 1);
|
|
|
|
V.Append(10, 1);
|
|
|
|
V.Sort();
|
|
|
|
V.CombineConsecutiveRanges();
|
|
|
|
EXPECT_THAT(V, testing::ElementsAre(Entry(0, 20)));
|
|
|
|
}
|
|
|
|
|
2022-02-11 10:18:59 +08:00
|
|
|
TEST(RangeVector, GetOverlaps) {
|
|
|
|
using RangeVector = RangeVector<uint32_t, uint32_t>;
|
|
|
|
|
|
|
|
RangeVector V1;
|
|
|
|
RangeVector V2;
|
|
|
|
RangeVector Expected;
|
|
|
|
// same range
|
|
|
|
V1.Append(0, 1);
|
|
|
|
V2.Append(0, 1);
|
|
|
|
Expected.Append(0, 1);
|
|
|
|
|
|
|
|
// no overlap
|
|
|
|
V1.Append(2, 2);
|
|
|
|
V2.Append(4, 1);
|
|
|
|
|
|
|
|
// same base overlap
|
|
|
|
V1.Append(10, 5);
|
|
|
|
V2.Append(10, 3);
|
|
|
|
Expected.Append(10, 3);
|
|
|
|
|
|
|
|
// same end overlap
|
|
|
|
V1.Append(27, 1);
|
|
|
|
V2.Append(20, 8);
|
|
|
|
Expected.Append(27, 1);
|
|
|
|
|
|
|
|
// smaller base overlap
|
|
|
|
V1.Append(33, 4);
|
|
|
|
V2.Append(30, 5);
|
|
|
|
Expected.Append(33, 2);
|
|
|
|
|
|
|
|
// larger base overlap
|
|
|
|
V1.Append(46, 3);
|
|
|
|
V2.Append(40, 7);
|
|
|
|
Expected.Append(46, 1);
|
|
|
|
|
|
|
|
// encompass 1 range
|
|
|
|
V1.Append(50, 9);
|
|
|
|
V2.Append(51, 7);
|
|
|
|
Expected.Append(51, 7);
|
|
|
|
|
|
|
|
// encompass 2 ranges
|
|
|
|
V1.Append(60, 9);
|
|
|
|
V2.Append(60, 3);
|
|
|
|
V2.Append(65, 3);
|
|
|
|
Expected.Append(60, 3);
|
|
|
|
Expected.Append(65, 3);
|
|
|
|
|
|
|
|
V1.Sort();
|
|
|
|
V2.Sort();
|
|
|
|
Expected.Sort();
|
|
|
|
|
|
|
|
EXPECT_EQ(RangeVector::GetOverlaps(V1, V2), Expected);
|
|
|
|
EXPECT_EQ(RangeVector::GetOverlaps(V2, V1), Expected);
|
|
|
|
}
|
|
|
|
|
RangeMap.h: merge RangeDataArray and RangeDataVector
Summary:
The main difference between the classes was supposed to be the fact that
one is backed by llvm::SmallVector, and the other by std::vector.
However, over the years, they have accumulated various other differences
too.
This essentially removes the std::vector version, as that is pretty much
identical to llvm::SmallVector<T, 0>, and combines their interfaces. It
does not attempt to do a more significant refactoring, even though there
is still a lot of duplication in this file, as it is hard to tell which
quirk of some API is depended on by somebody (and, a previous, more
ambitious attempt at this in D16769 has failed).
I also add some tests, including one which demonstrates one of the
quirks/bugs of the API I have noticed in the process.
Reviewers: clayborg, teemperor, tberghammer
Subscribers: mgorny, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56170
llvm-svn: 350380
2019-01-04 15:14:17 +08:00
|
|
|
using RangeDataVectorT = RangeDataVector<uint32_t, uint32_t, uint32_t>;
|
|
|
|
using EntryT = RangeDataVectorT::Entry;
|
|
|
|
|
|
|
|
static testing::Matcher<const EntryT *> EntryIs(uint32_t ID) {
|
|
|
|
return testing::Pointee(testing::Field(&EntryT::data, ID));
|
|
|
|
}
|
|
|
|
|
2020-02-26 23:43:43 +08:00
|
|
|
std::vector<uint32_t> FindEntryIndexes(uint32_t address, RangeDataVectorT map) {
|
|
|
|
std::vector<uint32_t> result;
|
|
|
|
map.FindEntryIndexesThatContain(address, result);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
RangeMap.h: merge RangeDataArray and RangeDataVector
Summary:
The main difference between the classes was supposed to be the fact that
one is backed by llvm::SmallVector, and the other by std::vector.
However, over the years, they have accumulated various other differences
too.
This essentially removes the std::vector version, as that is pretty much
identical to llvm::SmallVector<T, 0>, and combines their interfaces. It
does not attempt to do a more significant refactoring, even though there
is still a lot of duplication in this file, as it is hard to tell which
quirk of some API is depended on by somebody (and, a previous, more
ambitious attempt at this in D16769 has failed).
I also add some tests, including one which demonstrates one of the
quirks/bugs of the API I have noticed in the process.
Reviewers: clayborg, teemperor, tberghammer
Subscribers: mgorny, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56170
llvm-svn: 350380
2019-01-04 15:14:17 +08:00
|
|
|
TEST(RangeDataVector, FindEntryThatContains) {
|
|
|
|
RangeDataVectorT Map;
|
|
|
|
uint32_t NextID = 0;
|
|
|
|
Map.Append(EntryT(0, 10, NextID++));
|
|
|
|
Map.Append(EntryT(10, 10, NextID++));
|
|
|
|
Map.Append(EntryT(20, 10, NextID++));
|
|
|
|
Map.Sort();
|
|
|
|
|
|
|
|
EXPECT_THAT(Map.FindEntryThatContains(0), EntryIs(0));
|
|
|
|
EXPECT_THAT(Map.FindEntryThatContains(9), EntryIs(0));
|
|
|
|
EXPECT_THAT(Map.FindEntryThatContains(10), EntryIs(1));
|
|
|
|
EXPECT_THAT(Map.FindEntryThatContains(19), EntryIs(1));
|
|
|
|
EXPECT_THAT(Map.FindEntryThatContains(20), EntryIs(2));
|
|
|
|
EXPECT_THAT(Map.FindEntryThatContains(29), EntryIs(2));
|
|
|
|
EXPECT_THAT(Map.FindEntryThatContains(30), nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(RangeDataVector, FindEntryThatContains_Overlap) {
|
|
|
|
RangeDataVectorT Map;
|
|
|
|
uint32_t NextID = 0;
|
|
|
|
Map.Append(EntryT(0, 40, NextID++));
|
|
|
|
Map.Append(EntryT(10, 20, NextID++));
|
|
|
|
Map.Append(EntryT(20, 10, NextID++));
|
|
|
|
Map.Sort();
|
|
|
|
|
|
|
|
// With overlapping intervals, the intention seems to be to return the first
|
|
|
|
// interval which contains the address.
|
|
|
|
EXPECT_THAT(Map.FindEntryThatContains(25), EntryIs(0));
|
|
|
|
|
|
|
|
// However, this does not always succeed.
|
|
|
|
// TODO: This should probably return the range (0, 40) as well.
|
|
|
|
EXPECT_THAT(Map.FindEntryThatContains(35), nullptr);
|
|
|
|
}
|
2020-01-10 22:14:38 +08:00
|
|
|
|
|
|
|
TEST(RangeDataVector, CustomSort) {
|
|
|
|
// First the default ascending order sorting of the data field.
|
|
|
|
auto Map = RangeDataVectorT();
|
|
|
|
Map.Append(EntryT(0, 10, 50));
|
|
|
|
Map.Append(EntryT(0, 10, 52));
|
|
|
|
Map.Append(EntryT(0, 10, 53));
|
|
|
|
Map.Append(EntryT(0, 10, 51));
|
|
|
|
Map.Sort();
|
|
|
|
|
|
|
|
EXPECT_THAT(Map.GetSize(), 4);
|
|
|
|
EXPECT_THAT(Map.GetEntryRef(0).data, 50);
|
|
|
|
EXPECT_THAT(Map.GetEntryRef(1).data, 51);
|
|
|
|
EXPECT_THAT(Map.GetEntryRef(2).data, 52);
|
|
|
|
EXPECT_THAT(Map.GetEntryRef(3).data, 53);
|
|
|
|
|
|
|
|
// And then a custom descending order sorting of the data field.
|
|
|
|
class CtorParam {};
|
|
|
|
class CustomSort {
|
|
|
|
public:
|
|
|
|
CustomSort(CtorParam) {}
|
|
|
|
bool operator()(const uint32_t a_data, const uint32_t b_data) {
|
|
|
|
return a_data > b_data;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
using RangeDataVectorCustomSortT =
|
|
|
|
RangeDataVector<uint32_t, uint32_t, uint32_t, 0, CustomSort>;
|
|
|
|
using EntryT = RangeDataVectorT::Entry;
|
|
|
|
|
|
|
|
auto MapC = RangeDataVectorCustomSortT(CtorParam());
|
|
|
|
MapC.Append(EntryT(0, 10, 50));
|
|
|
|
MapC.Append(EntryT(0, 10, 52));
|
|
|
|
MapC.Append(EntryT(0, 10, 53));
|
|
|
|
MapC.Append(EntryT(0, 10, 51));
|
|
|
|
MapC.Sort();
|
|
|
|
|
|
|
|
EXPECT_THAT(MapC.GetSize(), 4);
|
|
|
|
EXPECT_THAT(MapC.GetEntryRef(0).data, 53);
|
|
|
|
EXPECT_THAT(MapC.GetEntryRef(1).data, 52);
|
|
|
|
EXPECT_THAT(MapC.GetEntryRef(2).data, 51);
|
|
|
|
EXPECT_THAT(MapC.GetEntryRef(3).data, 50);
|
|
|
|
}
|
2020-02-26 23:43:43 +08:00
|
|
|
|
|
|
|
TEST(RangeDataVector, FindEntryIndexesThatContain) {
|
|
|
|
RangeDataVectorT Map;
|
|
|
|
Map.Append(EntryT(0, 10, 10));
|
|
|
|
Map.Append(EntryT(10, 10, 11));
|
|
|
|
Map.Append(EntryT(20, 10, 12));
|
|
|
|
Map.Sort();
|
|
|
|
|
|
|
|
EXPECT_THAT(FindEntryIndexes(0, Map), testing::ElementsAre(10));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(9, Map), testing::ElementsAre(10));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(10, Map), testing::ElementsAre(11));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(19, Map), testing::ElementsAre(11));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(20, Map), testing::ElementsAre(12));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(29, Map), testing::ElementsAre(12));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(30, Map), testing::ElementsAre());
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(RangeDataVector, FindEntryIndexesThatContain_Overlap) {
|
|
|
|
RangeDataVectorT Map;
|
|
|
|
Map.Append(EntryT(0, 40, 10));
|
|
|
|
Map.Append(EntryT(10, 20, 11));
|
|
|
|
Map.Append(EntryT(20, 10, 12));
|
|
|
|
Map.Sort();
|
|
|
|
|
|
|
|
EXPECT_THAT(FindEntryIndexes(0, Map), testing::ElementsAre(10));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(9, Map), testing::ElementsAre(10));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(10, Map), testing::ElementsAre(10, 11));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(19, Map), testing::ElementsAre(10, 11));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(20, Map), testing::ElementsAre(10, 11, 12));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(29, Map), testing::ElementsAre(10, 11, 12));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(30, Map), testing::ElementsAre(10));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(39, Map), testing::ElementsAre(10));
|
|
|
|
EXPECT_THAT(FindEntryIndexes(40, Map), testing::ElementsAre());
|
|
|
|
}
|