Change-Id: I64307ccd0a6f23a7c3860d602813e637415e7c91

Change-Id: Ie7cc268a8823aec1d06c8b7cbef54068d832de3a

Also removed some trailing whitespace.

Change-Id: I40bf4f776ca4d467b7ee6f2c9a7500c13700f9d5

Bug: https://github.com/google/flatbuffers/issues/3872
Change-Id: I5d551168e9bc925e867e5e4ddf5d809418fd44eb
Tested: on Linux.

Use the build output flatc to compile test schemas by default.

Fix undefined behavior when CheckBitsFit left-shifts 64-bit value by 64 bits

Bug: 28762769
Change-Id: Iec370482f67c4585e97dd5175c1a4258ddba47fe
Tested: on Linux.

Fixed Library Location in CppUsage.md

Fixed Library Location 
"https://github.com/google/flatbuffers/tree/master/include/flatbuffers"
in CppUsage.md

Fix CreateString with already-encoded string or bytearray in Python 2.7.

Fix for #3853

Transition 1 (nice diffs) Go, C++ and General generators with class

Can now use ``CharSequence`` of ``String``.  Works with

1. [AsciiString]
(http://netty.io/4.1/api/io/netty/util/AsciiString.html)
2. [CharBuffer]
(https://docs.oracle.com/javase/8/docs/api/java/nio/CharBuffer.html)
3. [StringBuilder]
(https://docs.oracle.com/javase/8/docs/api/java/lang/StringBuilder.html)

Go: Fix heap allocation when reading a string.

Fix for #3849

Change-Id: I1aef5fdba72de0c3bb8276c9f50fffa494f26e29
Tested: on Linux.

Change-Id: Ie60f01d935ca6b4aa6ce0eab7598602ac0758342
Tested: on Linux.

This avoids the following allocations over repeated use:

- A ``CharsetEncoder``
- A byte array to contain the contents of the string
- A wrapper, via ``ByteBuffer#wrap``, for the previously mentioned byte
  array

This also removes a copy of the temporary byte array.  This extra copy
is needed because ``String#getBytes`` returns a byte array and its
length must match the exact size of the contents.

This implementation requires that the builder retain a ``ByteBuffer``
and ``CharEncoder``.  This is considered slower only for users that
will only allocate a single string in their buffers or none at all.

The improvement is especially potent if the builder is constantly reused
by its caller.  This also eliminates the penalty for users that do not
use strings at all since the cost of allocating these fields is
now amortized.

The only allocation left in this code is a ``CharBuffer`` wrapper.  It's
possible to eliminate this allocation using an additional copy but need
further profiling to see which is the bigger problem.

Change-Id: I8dcbb5e93836356511d411ef86452babd3dd3c0b
Tested: on Linux.

Removes the following allocations:
- ``CharsetDecoder`` is reused between calls
- ``CharBuffer#wrap`` removed in favor of heap
  based char buffer that is reused
- Temporary ``char[]``, an intermediate copy inside ``StringCoding``
- Another ``char[]``, this is needed because ``StringCoding`` uses
  a ``CharBuffer`` internally but returns a ``char[]``.  Extra
  characters need to be trimmed so this means yet another allocation
- Yet another ``char[]`` directly from ``__string`` for non-heap
  based buffers

Removes the following copies
- No copy is performed to trim the allocation since a ``CharBuffer``
  is used directly
- For non-heap based byte buffers, removes the copy that was
  previously done in the __string function

This does need to get the TLS entry which implies at least some
contention on the thread object table and a fence.

Fix for 3847

A previous commit that added "f" for C++/Java/C# would break
on gcc of constants like 3f, which are now output as 3.0f

Tested: on Linux

Change-Id: If9cabbe3c6d6948a5050b8b123bda9c06e181f52

Bug: 28145201
Change-Id: I5a1818c40c2f4fbd00cfec3362040407976f7a39
Tested: on Linux.

Stop CreateUninitializedVector returning a pointer to invalid memory.

CreateUninitializedVector was performing the following actions:
    1. call StartVector.
    2. call make_space, and set buf to point to the reserved space.
    3. call EndVector.

The problem is that a call to EndVector can ultimately call make_space, which
if the buffer is full, will cause a reallocation, invalidating the value stored
in buf.  So setting buf needs to be delayed until after EndVector.

The following code, when run under valgrind shows a write to free'd memory before
the change, but no such error after:

int main()
{
    flatbuffers::FlatBufferBuilder fbb(128);
    char *buf = nullptr;
    fbb.CreateUninitializedVector(128, &buf);
    *buf = 0;
}

Change-Id: I3730a6823d603982c4250d514e827e3f93d1f81e
Tested: on Linux.