| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Similar to std::unordered_map::insert_or_assign
Reviewers: alexshap, bkramer, dblaikie, lhames
Subscribers: jkorous, dexonsmith, kristina, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67668
llvm-svn: 372813
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Re-land r362766 after it was reverted in r362823.
Reviewers: jhenderson, dsanders, aaron.ballman, MatzeB, lhames, dblaikie
Reviewed By: dblaikie
Subscribers: smeenai, mgrang, mgorny, dexonsmith, kristina, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62369
llvm-svn: 362835
|
|
|
|
|
|
|
|
| |
This reverts commit 0bddef79019a23ab14fcdb27028e55e484674c88, it was
causing ASan failures on the sanitizer bots:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/32800
llvm-svn: 362823
|
|
|
|
|
|
|
|
|
|
| |
Subscribers: mgorny, mgrang, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62992
llvm-svn: 362766
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The convenience wrapper in STLExtras is available since rL342102.
Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb
Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D52573
llvm-svn: 343163
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r327219 added wrappers to std::sort which randomly shuffle the container before
sorting. This will help in uncovering non-determinism caused due to undefined
sorting order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of
std::sort.
Note: This patch is one of a series of patches to replace *all* std::sort to
llvm::sort. Refer the comments section in D44363 for a list of all the
required patches.
llvm-svn: 329475
|
|
|
|
|
|
|
|
| |
rather than unsigned.
Patch by Matt Davis.
llvm-svn: 322305
|
|
|
|
| |
llvm-svn: 299197
|
|
|
|
|
|
|
| |
The issue was trying to advance past the end of the iterator
when computing the end() iterator.
llvm-svn: 298461
|
|
|
|
|
|
|
| |
This is causing crashes in clang, so reverting until the problem
is figured out.
llvm-svn: 298440
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
StringMap's iterators did not support LLVM's
iterator_facade_base, which made it unusable in various
STL algorithms or with some of our range adapters.
This patch makes both StringMapConstIterator as well as
StringMapIterator support iterator_facade_base.
With this in place, it is easy to make an iterator adapter
that iterates over only keys, and whose value_type is
StringRef. So I add StringMapKeyIterator as well, and
provide the method StringMap::keys() that returns a
range that can be iterated.
Differential Revision: https://reviews.llvm.org/D31171
llvm-svn: 298436
|
|
|
|
|
|
|
| |
Coincidentally this function maps to the C++17 try_emplace. Rename it
for consistentcy with C++17 std::map. NFC.
llvm-svn: 276276
|
|
|
|
|
|
|
|
|
|
|
| |
declarations (NFC)
Differential Revision: http://reviews.llvm.org/D19154
Patch by Eugene Kosov <claprix@yandex.ru>
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266524
|
|
|
|
|
|
|
|
|
|
| |
There is code under review that requires StringMap to have a copy constructor,
and this makes StringMap more consistent with our other containers (like
DenseMap) that have copy constructors.
Differential Revision: http://reviews.llvm.org/D18506
llvm-svn: 264906
|
|
|
|
|
|
|
|
| |
This makes us no longer relying on move-construction elision by the compiler.
Suggested by D. Blaikie.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264475
|
|
|
|
|
|
|
| |
std::pair internals
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264418
|
|
|
|
|
|
|
| |
pre-allocation/reserve
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264416
|
|
|
|
|
|
|
| |
move-construction elision
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264412
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Loading IR with debug info improves MDString::get() from 19ms to 10ms.
This is a rework of D16597 with adding an "emplace" method on the StringMap
to avoid requiring the MDString move ctor to be public.
Reviewers: dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17920
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264386
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
StringMap ctor accepts an initialize size, but expect it to be
rounded to the next power of 2. The ctor can handle that directly
instead of expecting clients to round it. Also, since the map will
resize itself when 75% full, take this into account an initialize
a larger initial size to avoid any growth.
Reviewers: dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18344
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264385
|
|
|
|
|
|
| |
requiring the macro. NFC; LLVM edition.
llvm-svn: 229340
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having two ways to do this doesn't seem terribly helpful and
consistently using the insert version (which we already has) seems like
it'll make the code easier to understand to anyone working with standard
data structures. (I also updated many references to the Entry's
key and value to use first() and second instead of getKey{Data,Length,}
and get/setValue - for similar consistency)
Also removes the GetOrCreateValue functions so there's less surface area
to StringMap to fix/improve/change/accommodate move semantics, etc.
llvm-svn: 222319
|
|
|
|
|
|
|
|
| |
StringMap operations.
Followup to r221946.
llvm-svn: 221958
|
|
|
|
|
|
|
|
|
|
|
|
| |
private, but non-deleted, move members.
Certain versions of GCC (~4.7) couldn't handle the SFINAE on access
control, but with "= delete" (hidden behind a macro for portability)
this issue is worked around/addressed.
Patch by Agustín Bergé
llvm-svn: 211525
|
|
|
|
|
|
|
|
|
|
|
|
| |
container concept."
This reverts commit r211309.
It looks like it broke some bots:
http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/15563/steps/compile/logs/stdio
llvm-svn: 211328
|
|
|
|
|
|
|
|
| |
container concept.
Patch by Agustín Bergé.
llvm-svn: 211309
|
|
|
|
|
|
| |
pointers. Simpliies all in tree call sites. No functional change.
llvm-svn: 210638
|
|
|
|
| |
llvm-svn: 208388
|
|
|
|
| |
llvm-svn: 208362
|
|
|
|
| |
llvm-svn: 208361
|
|
|
|
| |
llvm-svn: 208359
|
|
|
|
|
|
| |
parameter.
llvm-svn: 198379
|
|
|
|
|
|
|
|
|
| |
This functionality was enabled by r198374. Here's a test to ensure it
works and we don't regress it.
Based on a patch by Maciej Piechotka.
llvm-svn: 198377
|
|
|
|
|
|
|
| |
It was never specialized so let's just remove that unused
configurability and always do the default.
llvm-svn: 198374
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
StringMap suffered from the same bug as DenseMap: when you explicitly
construct it with a small number of buckets, you can arrange for the
tombstone-based growth path to be followed when the number of buckets
was less than '8'. In that case, even with a full map, it would compare
'0' as not less than '0', and refuse to grow the table, leading to
inf-loops trying to find an empty bucket on the next insertion. The fix
is very simple: use '<=' as the comparison. The same fix was applied to
DenseMap as well during its recent refactoring.
Thanks to Alex Bolz for the great report and test case. =]
llvm-svn: 158725
|
|
|
|
|
|
|
| |
GoogleTest already prints errors with all the information about which
test case contained the error.
llvm-svn: 158724
|
|
|
|
|
|
| |
const char* doesn't make sense. Have it return StringRef instead.
llvm-svn: 135167
|
|
|
|
| |
llvm-svn: 120298
|
|
|
|
| |
llvm-svn: 95862
|
|
|
|
|
|
| |
direct inclusion edge from System to Support.
llvm-svn: 85086
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Yay for '-'s and simplifications!
- I kept StringMap::GetOrCreateValue for compatibility purposes, this can
eventually go away. Likewise the StringMapEntry Create functions still follow
the old style.
- NIFC.
llvm-svn: 76888
|
|
|
|
| |
llvm-svn: 76542
|
|
|
|
|
|
| |
specialization apply only to the tests that are actually testing it.
llvm-svn: 61923
|
|
|
|
|
|
|
|
|
| |
StringMapEntryInitializer classes. Leave it for the compiler to figure out what
the type is and what "0" should be transformed into.
* Un-disable the unit tests which test the StringMapEntryInitializer class.
llvm-svn: 61922
|
|
|
|
| |
llvm-svn: 61919
|
|
* Fixed but in StringMap::clear()
* Removed trailing whitespace
Original patch by Talin.
llvm-svn: 61914
|