directly care about the Value class (it is templated so that the key can
be any arbitrary Value subclass), it is in fact concretely tied to the
Value class through the ValueHandle's CallbackVH interface which relies
on the key type being some Value subclass to establish the value handle
chain.
Ironically, the unittest is already in the right library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202824 91177308-0d34-0410-b5e6-96231b3b80d8
std::lower_bound is the canonical "binary search" in the STL
(std::binary_search generally is not what you want). The name actually
makes a lot of sense (and also has a beautiful symmetry with the
std::upper_bound algorithm). The name is nonetheless non-obvious.
Also, remove mention of "radix search". It's not even clear how that
would work in the context of a sorted vector. AFAIK "radix search" only
makes sense when you have a trie-like data structure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178376 91177308-0d34-0410-b5e6-96231b3b80d8
The new wording cannot be construed as suggesting the use of
SmallVectorImpl<T> as e.g. a class member (just because the class
happens to be in an interface).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177778 91177308-0d34-0410-b5e6-96231b3b80d8
Before we learned about :doc:, we used :ref: and put a dummy link at the
top of each page. Don't do that anymore.
This fixes PR14891 as a special case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172162 91177308-0d34-0410-b5e6-96231b3b80d8
against the developer policy to include this sort of thing as SVN blame
already captures this in a far more fine-grained way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172109 91177308-0d34-0410-b5e6-96231b3b80d8
Apparently Dinkumware are no longer hosting their nice reference
manuals. Thankfully, `cppreference.com` can fill that role well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169210 91177308-0d34-0410-b5e6-96231b3b80d8
