2010-05-13 05:35:19 +08:00
|
|
|
//===- llvm/unittest/ADT/APInt.cpp - APInt unit tests ---------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/ADT/ilist.h"
|
Add an assertion for a likely ilist::splice() contract violation.
The single-element ilist::splice() function supports a noop move:
List.splice(I, List, I);
The corresponding std::list function doesn't allow that, so add a unit
test to document that behavior.
This also means that
List.splice(I, List, F);
is somewhat surprisingly not equivalent to
List.splice(I, List, F, next(F));
This patch adds an assertion to catch the illegal case I == F above.
Alternatively, we could make I == F a legal noop, but that would make
ilist differ even more from std::list.
llvm-svn: 170443
2012-12-19 03:28:37 +08:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2013-01-02 18:26:28 +08:00
|
|
|
#include "llvm/ADT/ilist_node.h"
|
2012-12-04 18:23:08 +08:00
|
|
|
#include "gtest/gtest.h"
|
|
|
|
#include <ostream>
|
2010-05-13 05:35:19 +08:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
struct Node : ilist_node<Node> {
|
|
|
|
int Value;
|
|
|
|
|
|
|
|
Node() {}
|
2015-03-05 01:01:18 +08:00
|
|
|
Node(int Value) : Value(Value) {}
|
|
|
|
Node(const Node&) = default;
|
2013-01-05 06:35:42 +08:00
|
|
|
~Node() { Value = -1; }
|
2010-05-13 05:35:19 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
TEST(ilistTest, Basic) {
|
|
|
|
ilist<Node> List;
|
|
|
|
List.push_back(Node(1));
|
|
|
|
EXPECT_EQ(1, List.back().Value);
|
ADT: Avoid relying on UB in ilist_node::getNextNode()
Re-implement `ilist_node::getNextNode()` and `getPrevNode()` without
relying on the sentinel having a "next" pointer. Instead, get access to
the owning list and compare against the `begin()` and `end()` iterators.
This only works when the node *can* get access to the owning list. The
new support is in `ilist_node_with_parent<>`, and any class `Ty`
inheriting from `ilist_node<NodeTy>` that wants `getNextNode()` and/or
`getPrevNode()` should inherit from
`ilist_node_with_parent<NodeTy, ParentTy>` instead. The requirements:
- `NodeTy` must have a `getParent()` function that returns the parent.
- `ParentTy` must have a `getSublistAccess()` static that, given a(n
ignored) `NodeTy*` (to determine which list), returns a member field
pointer to the appropriate `ilist<>`.
This isn't the cleanest way to get access to the owning list, but it
leverages the API already used in the IR hierarchy (see, e.g.,
`Instruction::getSublistAccess()`).
If anyone feels like ripping out the calls to `getNextNode()` and
`getPrevNode()` and replacing with direct iterator logic, they can also
remove the access function, etc., but as an incremental step, I'm
maintaining the API where it's currently used in tree.
If these requirements are *not* met, call sites with access to the ilist
can call `iplist<NodeTy>::getNextNode(NodeTy*)` directly, as in
ilistTest.cpp.
Why rewrite this?
The old code was broken, calling `getNext()` on a sentinel that possibly
didn't have a "next" pointer at all! The new code avoids that
particular flavour of UB (see the commit message for r252538 for more
details about the "lucky" memory layout that made this function so
interesting).
There's still some UB here: the end iterator gets downcast to `NodeTy*`,
even when it's a sentinel (which is typically
`ilist_half_node<NodeTy*>`). I'll tackle that in follow-up commits.
See this llvm-dev thread for more details:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091115.html
What's the danger?
There might be some code that relies on `getNextNode()` or
`getPrevNode()` *never* returning `nullptr` -- i.e., that relies on them
being broken when the sentinel is an `ilist_half_node<NodeTy>`. I tried
to root out those cases with the audits I did leading up to r252380, but
it's possible I missed one or two. I hope not.
(If (1) you have out-of-tree code, (2) you've reverted r252380
temporarily, and (3) you get some weird crashes with this commit, then I
recommend un-reverting r252380 and auditing the compile errors looking
for "strange" implicit conversions.)
llvm-svn: 252694
2015-11-11 10:26:42 +08:00
|
|
|
EXPECT_EQ(nullptr, List.getPrevNode(List.back()));
|
|
|
|
EXPECT_EQ(nullptr, List.getNextNode(List.back()));
|
2010-05-13 05:35:19 +08:00
|
|
|
|
|
|
|
List.push_back(Node(2));
|
|
|
|
EXPECT_EQ(2, List.back().Value);
|
ADT: Avoid relying on UB in ilist_node::getNextNode()
Re-implement `ilist_node::getNextNode()` and `getPrevNode()` without
relying on the sentinel having a "next" pointer. Instead, get access to
the owning list and compare against the `begin()` and `end()` iterators.
This only works when the node *can* get access to the owning list. The
new support is in `ilist_node_with_parent<>`, and any class `Ty`
inheriting from `ilist_node<NodeTy>` that wants `getNextNode()` and/or
`getPrevNode()` should inherit from
`ilist_node_with_parent<NodeTy, ParentTy>` instead. The requirements:
- `NodeTy` must have a `getParent()` function that returns the parent.
- `ParentTy` must have a `getSublistAccess()` static that, given a(n
ignored) `NodeTy*` (to determine which list), returns a member field
pointer to the appropriate `ilist<>`.
This isn't the cleanest way to get access to the owning list, but it
leverages the API already used in the IR hierarchy (see, e.g.,
`Instruction::getSublistAccess()`).
If anyone feels like ripping out the calls to `getNextNode()` and
`getPrevNode()` and replacing with direct iterator logic, they can also
remove the access function, etc., but as an incremental step, I'm
maintaining the API where it's currently used in tree.
If these requirements are *not* met, call sites with access to the ilist
can call `iplist<NodeTy>::getNextNode(NodeTy*)` directly, as in
ilistTest.cpp.
Why rewrite this?
The old code was broken, calling `getNext()` on a sentinel that possibly
didn't have a "next" pointer at all! The new code avoids that
particular flavour of UB (see the commit message for r252538 for more
details about the "lucky" memory layout that made this function so
interesting).
There's still some UB here: the end iterator gets downcast to `NodeTy*`,
even when it's a sentinel (which is typically
`ilist_half_node<NodeTy*>`). I'll tackle that in follow-up commits.
See this llvm-dev thread for more details:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091115.html
What's the danger?
There might be some code that relies on `getNextNode()` or
`getPrevNode()` *never* returning `nullptr` -- i.e., that relies on them
being broken when the sentinel is an `ilist_half_node<NodeTy>`. I tried
to root out those cases with the audits I did leading up to r252380, but
it's possible I missed one or two. I hope not.
(If (1) you have out-of-tree code, (2) you've reverted r252380
temporarily, and (3) you get some weird crashes with this commit, then I
recommend un-reverting r252380 and auditing the compile errors looking
for "strange" implicit conversions.)
llvm-svn: 252694
2015-11-11 10:26:42 +08:00
|
|
|
EXPECT_EQ(2, List.getNextNode(List.front())->Value);
|
|
|
|
EXPECT_EQ(1, List.getPrevNode(List.back())->Value);
|
2010-05-14 02:35:02 +08:00
|
|
|
|
|
|
|
const ilist<Node> &ConstList = List;
|
|
|
|
EXPECT_EQ(2, ConstList.back().Value);
|
ADT: Avoid relying on UB in ilist_node::getNextNode()
Re-implement `ilist_node::getNextNode()` and `getPrevNode()` without
relying on the sentinel having a "next" pointer. Instead, get access to
the owning list and compare against the `begin()` and `end()` iterators.
This only works when the node *can* get access to the owning list. The
new support is in `ilist_node_with_parent<>`, and any class `Ty`
inheriting from `ilist_node<NodeTy>` that wants `getNextNode()` and/or
`getPrevNode()` should inherit from
`ilist_node_with_parent<NodeTy, ParentTy>` instead. The requirements:
- `NodeTy` must have a `getParent()` function that returns the parent.
- `ParentTy` must have a `getSublistAccess()` static that, given a(n
ignored) `NodeTy*` (to determine which list), returns a member field
pointer to the appropriate `ilist<>`.
This isn't the cleanest way to get access to the owning list, but it
leverages the API already used in the IR hierarchy (see, e.g.,
`Instruction::getSublistAccess()`).
If anyone feels like ripping out the calls to `getNextNode()` and
`getPrevNode()` and replacing with direct iterator logic, they can also
remove the access function, etc., but as an incremental step, I'm
maintaining the API where it's currently used in tree.
If these requirements are *not* met, call sites with access to the ilist
can call `iplist<NodeTy>::getNextNode(NodeTy*)` directly, as in
ilistTest.cpp.
Why rewrite this?
The old code was broken, calling `getNext()` on a sentinel that possibly
didn't have a "next" pointer at all! The new code avoids that
particular flavour of UB (see the commit message for r252538 for more
details about the "lucky" memory layout that made this function so
interesting).
There's still some UB here: the end iterator gets downcast to `NodeTy*`,
even when it's a sentinel (which is typically
`ilist_half_node<NodeTy*>`). I'll tackle that in follow-up commits.
See this llvm-dev thread for more details:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091115.html
What's the danger?
There might be some code that relies on `getNextNode()` or
`getPrevNode()` *never* returning `nullptr` -- i.e., that relies on them
being broken when the sentinel is an `ilist_half_node<NodeTy>`. I tried
to root out those cases with the audits I did leading up to r252380, but
it's possible I missed one or two. I hope not.
(If (1) you have out-of-tree code, (2) you've reverted r252380
temporarily, and (3) you get some weird crashes with this commit, then I
recommend un-reverting r252380 and auditing the compile errors looking
for "strange" implicit conversions.)
llvm-svn: 252694
2015-11-11 10:26:42 +08:00
|
|
|
EXPECT_EQ(2, ConstList.getNextNode(ConstList.front())->Value);
|
|
|
|
EXPECT_EQ(1, ConstList.getPrevNode(ConstList.back())->Value);
|
2010-05-13 05:35:19 +08:00
|
|
|
}
|
|
|
|
|
Add an assertion for a likely ilist::splice() contract violation.
The single-element ilist::splice() function supports a noop move:
List.splice(I, List, I);
The corresponding std::list function doesn't allow that, so add a unit
test to document that behavior.
This also means that
List.splice(I, List, F);
is somewhat surprisingly not equivalent to
List.splice(I, List, F, next(F));
This patch adds an assertion to catch the illegal case I == F above.
Alternatively, we could make I == F a legal noop, but that would make
ilist differ even more from std::list.
llvm-svn: 170443
2012-12-19 03:28:37 +08:00
|
|
|
TEST(ilistTest, SpliceOne) {
|
|
|
|
ilist<Node> List;
|
|
|
|
List.push_back(1);
|
|
|
|
|
|
|
|
// The single-element splice operation supports noops.
|
|
|
|
List.splice(List.begin(), List, List.begin());
|
|
|
|
EXPECT_EQ(1u, List.size());
|
|
|
|
EXPECT_EQ(1, List.front().Value);
|
2014-03-02 20:27:27 +08:00
|
|
|
EXPECT_TRUE(std::next(List.begin()) == List.end());
|
Add an assertion for a likely ilist::splice() contract violation.
The single-element ilist::splice() function supports a noop move:
List.splice(I, List, I);
The corresponding std::list function doesn't allow that, so add a unit
test to document that behavior.
This also means that
List.splice(I, List, F);
is somewhat surprisingly not equivalent to
List.splice(I, List, F, next(F));
This patch adds an assertion to catch the illegal case I == F above.
Alternatively, we could make I == F a legal noop, but that would make
ilist differ even more from std::list.
llvm-svn: 170443
2012-12-19 03:28:37 +08:00
|
|
|
|
|
|
|
// Altenative noop. Move the first element behind itself.
|
|
|
|
List.push_back(2);
|
|
|
|
List.push_back(3);
|
2014-03-02 20:27:27 +08:00
|
|
|
List.splice(std::next(List.begin()), List, List.begin());
|
Add an assertion for a likely ilist::splice() contract violation.
The single-element ilist::splice() function supports a noop move:
List.splice(I, List, I);
The corresponding std::list function doesn't allow that, so add a unit
test to document that behavior.
This also means that
List.splice(I, List, F);
is somewhat surprisingly not equivalent to
List.splice(I, List, F, next(F));
This patch adds an assertion to catch the illegal case I == F above.
Alternatively, we could make I == F a legal noop, but that would make
ilist differ even more from std::list.
llvm-svn: 170443
2012-12-19 03:28:37 +08:00
|
|
|
EXPECT_EQ(3u, List.size());
|
|
|
|
EXPECT_EQ(1, List.front().Value);
|
2014-03-02 20:27:27 +08:00
|
|
|
EXPECT_EQ(2, std::next(List.begin())->Value);
|
Add an assertion for a likely ilist::splice() contract violation.
The single-element ilist::splice() function supports a noop move:
List.splice(I, List, I);
The corresponding std::list function doesn't allow that, so add a unit
test to document that behavior.
This also means that
List.splice(I, List, F);
is somewhat surprisingly not equivalent to
List.splice(I, List, F, next(F));
This patch adds an assertion to catch the illegal case I == F above.
Alternatively, we could make I == F a legal noop, but that would make
ilist differ even more from std::list.
llvm-svn: 170443
2012-12-19 03:28:37 +08:00
|
|
|
EXPECT_EQ(3, List.back().Value);
|
|
|
|
}
|
|
|
|
|
2013-01-05 06:35:42 +08:00
|
|
|
TEST(ilistTest, UnsafeClear) {
|
|
|
|
ilist<Node> List;
|
|
|
|
|
|
|
|
// Before even allocating a sentinel.
|
|
|
|
List.clearAndLeakNodesUnsafely();
|
|
|
|
EXPECT_EQ(0u, List.size());
|
|
|
|
|
|
|
|
// Empty list with sentinel.
|
|
|
|
ilist<Node>::iterator E = List.end();
|
|
|
|
List.clearAndLeakNodesUnsafely();
|
|
|
|
EXPECT_EQ(0u, List.size());
|
|
|
|
// The sentinel shouldn't change.
|
|
|
|
EXPECT_TRUE(E == List.end());
|
|
|
|
|
|
|
|
// List with contents.
|
|
|
|
List.push_back(1);
|
|
|
|
ASSERT_EQ(1u, List.size());
|
2015-10-21 02:30:20 +08:00
|
|
|
Node *N = &*List.begin();
|
2013-01-05 06:35:42 +08:00
|
|
|
EXPECT_EQ(1, N->Value);
|
|
|
|
List.clearAndLeakNodesUnsafely();
|
|
|
|
EXPECT_EQ(0u, List.size());
|
|
|
|
ASSERT_EQ(1, N->Value);
|
|
|
|
delete N;
|
|
|
|
|
|
|
|
// List is still functional.
|
|
|
|
List.push_back(5);
|
|
|
|
List.push_back(6);
|
|
|
|
ASSERT_EQ(2u, List.size());
|
|
|
|
EXPECT_EQ(5, List.front().Value);
|
|
|
|
EXPECT_EQ(6, List.back().Value);
|
|
|
|
}
|
|
|
|
|
2010-05-13 05:35:19 +08:00
|
|
|
}
|