intermediate changes

ref:cde9a383711a11544ce7e107a78147fb96cc4029

1 files changed, 193 insertions, 0 deletions

diff --git a/contrib/libs/sparsehash/NEWS b/contrib/libs/sparsehash/NEWS
new file mode 100644
index 0000000000..4af929c394
--- /dev/null
+++ b/contrib/libs/sparsehash/NEWS
@@ -0,0 +1,193 @@
+== 12 October 2015 ==
+
+Various small fixes to ensure compilation on modern compilers and operating 
+systems. Tagged as 2.0.3
+
+== 23 February 2012 ==
+
+A backwards incompatibility arose from flattening the include headers
+structure for the <google> folder. 
+
+This is now fixed in 2.0.2. You only need to upgrade if you had previously
+included files from the <google/sparsehash> folder.
+
+== 1 February 2012 ==
+
+A minor bug related to the namespace switch from google to sparsehash
+stopped the build from working when perftools is also installed.
+
+This is now fixed in 2.0.1. You only need to upgrade if you have perftools
+installed.  
+
+== 31 January 2012 ==
+
+I've just released sparsehash 2.0.
+
+The `google-sparsehash` project has been renamed to `sparsehash`.  I
+(csilvers) am stepping down as maintainer, to be replaced by the team
+of Donovan Hide and Geoff Pike.  Welcome to the team, Donovan and
+Geoff!  Donovan has been an active contributor to sparsehash bug
+reports and discussions in the past, and Geoff has been closely
+involved with sparsehash inside Google (in addition to writing the
+[http://code.google.com/p/cityhash CityHash hash function]).  The two
+of them together should be a formidable force.  For good.
+
+I bumped the major version number up to 2 to reflect the new community
+ownership of the project.  All the
+[http://sparsehash.googlecode.com/svn/tags/sparsehash-2.0/ChangeLog changes]
+are related to the renaming.
+
+The only functional change from sparsehash 1.12 is that I've renamed
+the `google/` include-directory to be `sparsehash/` instead.  New code
+should `#include <sparsehash/sparse_hash_map>`/etc.  I've kept the old
+names around as forwarding headers to the new, so `#include
+<google/sparse_hash_map>` will continue to work.
+
+Note that the classes and functions remain in the `google` C++
+namespace (I didn't change that to `sparsehash` as well); I think
+that's a trickier transition, and can happen in a future release.
+
+
+=== 18 January 2011 ===
+
+The `google-sparsehash` Google Code page has been renamed to
+`sparsehash`, in preparation for the project being renamed to
+`sparsehash`.  In the coming weeks, I'll be stepping down as
+maintainer for the sparsehash project, and as part of that Google is
+relinquishing ownership of the project; it will now be entirely
+community run.  The name change reflects that shift.
+
+
+=== 20 December 2011 ===
+
+I've just released sparsehash 1.12.  This release features improved
+I/O (serialization) support.  Support is finally added to serialize
+and unserialize `dense_hash_map`/`set`, paralleling the existing code
+for `sparse_hash_map`/`set`.  In addition, the serialization API has
+gotten simpler, with a single `serialize()` method to write to disk,
+and an `unserialize()` method to read from disk.  Finally, support has
+gotten more generic, with built-in support for both C `FILE*`s and C++
+streams, and an extension mechanism to support arbitrary sources and
+sinks.
+
+There are also more minor changes, including minor bugfixes, an
+improved deleted-key test, and a minor addition to the `sparsetable`
+API.  See the [http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.12/ChangeLog ChangeLog]
+for full details.
+
+=== 23 June 2011 ===
+
+I've just released sparsehash 1.11.  The major user-visible change is
+that the default behavior is improved -- using the hash_map/set is
+faster -- for hashtables where the key is a pointer.  We now notice
+that case and ignore the low 2-3 bits (which are almost always 0 for
+pointers) when hashing.
+
+Another user-visible change is we've removed the tests for whether the
+STL (vector, pair, etc) is defined in the 'std' namespace.  gcc 2.95
+is the most recent compiler I know of to put STL types and functions
+in the global namespace.  If you need to use such an old compiler, do
+not update to the latest sparsehash release.
+
+We've also changed the internal tools we use to integrate
+Googler-supplied patches to sparsehash into the opensource release.
+These new tools should result in more frequent updates with better
+change descriptions.  They will also result in future ChangeLog
+entries being much more verbose (for better or for worse).
+
+A full list of changes is described in 
+[http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.11/ChangeLog ChangeLog].
+
+=== 21 January 2011 ===
+
+I've just released sparsehash 1.10.  This fixes a performance
+regression in sparsehash 1.8, where sparse_hash_map would copy
+hashtable keys by value even when the key was explicitly a reference.
+It also fixes compiler warnings from MSVC 10, which uses some c++0x
+features that did not interact well with sparsehash.
+
+There is no reason to upgrade unless you use references for your
+hashtable keys, or compile with MSVC 10.  A full list of changes is
+described in
+[http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.10/ChangeLog ChangeLog].
+
+
+=== 24 September 2010 ===
+
+I've just released sparsehash 1.9.  This fixes a size regression in
+sparsehash 1.8, where the new allocator would take up space in
+`sparse_hash_map`, doubling the sparse_hash_map overhead (from 1-2
+bits per bucket to 3 or so).  All users are encouraged to upgrade.
+
+This change also marks enums as being Plain Old Data, which can speed
+up hashtables with enum keys and/or values.  A full list of changes is
+described in
+[http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.9/ChangeLog ChangeLog].
+
+=== 29 July 2010 ===
+
+I've just released sparsehash 1.8.  This includes improved support for
+`Allocator`, including supporting the allocator constructor arg and
+`get_allocator()` access method.
+
+To work around a bug in gcc 4.0.x, I've renamed the static variables
+`HT_OCCUPANCY_FLT` and `HT_SHRINK_FLT` to `HT_OCCUPANCY_PCT` and
+`HT_SHRINK_PCT`, and changed their type from float to int.  This
+should not be a user-visible change, since these variables are only
+used in the internal hashtable classes (sparsehash clients should use
+`max_load_factor()` and `min_load_factor()` instead of modifying these
+static variables), but if you do access these constants, you will need
+to change your code.
+
+Internally, the biggest change is a revamp of the test suite.  It now
+has more complete coverage, and a more capable timing tester.  There
+are other, more minor changes as well.  A full list of changes is
+described in the
+[http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.8/ChangeLog ChangeLog].
+
+=== 31 March 2010 ===
+
+I've just released sparsehash 1.7.  The major news here is the
+addition of `Allocator` support.  Previously, these hashtable classes
+would just ignore the `Allocator` template parameter.  They now
+respect it, and even inherit `size_type`, `pointer`, etc. from the
+allocator class.  By default, they use a special allocator we provide
+that uses libc `malloc` and `free` to allocate.  The hash classes
+notice when this special allocator is being used, and use `realloc`
+when it can.  This means that the default allocator is significantly
+faster than custom allocators are likely to be (since realloc-like
+functionality is not supported by STL allocators).
+
+There are a few more minor changes as well.  A full list of changes is
+described in the
+[http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.7/ChangeLog ChangeLog].
+
+=== 11 January 2010 ===
+
+I've just released sparsehash 1.6.  The API has widened a bit with the
+addition of `deleted_key()` and `empty_key()`, which let you query
+what values these keys have.  A few rather obscure bugs have been
+fixed (such as an error when copying one hashtable into another when
+the empty_keys differ).  A full list of changes is described in the
+[http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.6/ChangeLog ChangeLog].
+
+=== 9 May 2009 ===
+
+I've just released sparsehash 1.5.1.  Hot on the heels of sparsehash
+1.5, this release fixes a longstanding bug in the sparsehash code,
+where `equal_range` would always return an empty range.  It now works
+as documented.  All sparsehash users are encouraged to upgrade.
+
+=== 7 May 2009 ===
+
+I've just released sparsehash 1.5.  This release introduces tr1
+compatibility: I've added `rehash`, `begin(i)`, and other methods that
+are expected to be part of the `unordered_map` API once `tr1` in
+introduced.  This allows `sparse_hash_map`, `dense_hash_map`,
+`sparse_hash_set`, and `dense_hash_set` to be (almost) drop-in
+replacements for `unordered_map` and `unordered_set`.
+
+There is no need to upgrade unless you need this functionality, or
+need one of the other, more minor, changes described in the
+[http://google-sparsehash.googlecode.com/svn/tags/sparsehash-1.5/ChangeLog ChangeLog].
+