| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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
|