Fix Bison paths

Some internal FB bison version thing?
Merge pull request #783 from rlerdorf/patch-3

Fix Bison paths
add travis CI

To do this, I had to encode the wiki instructions in a file, which
seemed like a good thing anyways.
Update folly
Use AtomicHashMap for NamedEntities and StaticStrings

Its faster as long as you have a good starting point.
Add RuntimeOptions to specify initial sizes.
Merge pull request #763 from ptarjan/travis

add travis CI
Update README.md

Link to our pretty travis image
Adjust some debugger logging around the communications channel, and ensure we check all error conditions before attempting to read data from the socket

The error handling around the communication channel between client and server is a bit sketchy right now. We have some cases that are reasonable when the client is quitting and the socket is closing, and some cases where it would be surprising for this to happen. This leads to spurious messages printed out when quitting the client normally. For now, switch some of these to trace messages instead of log messages. Task 2398988 tracks cleaning this up properly.
Famous last bug in PolicyArray

PolicyArray pased all tests but failed in production. After browsing on my own box I figured that what happened was the method addLval() with a string key is called in production on many pages, but never in the tests. @ptarjan maybe you could look into adding such a test?

This diff still does not instantiate the policy-based array (I did instantiate it during testing).
Limit huge pages to the hot portion of the TC.

Huge pages are a limited system resource. When we ask for
huge chunks of system ram as huge pages, the kernel may actually do
physical memcpy's to satisfy our desires, burning CPU.

Only use huge pages on the portion of the TC that Bert's data shows to
be hot.
Fix user defined sorting

copy paste error crept in a few weeks ago, breaking the
case of a user-defined function that returns boolean.
Fix another flakey zend test
Tolerate "isset($c->prop)" for collections

Currently collections define magic __get, __set, __isset, and __unset
methods which will throw exceptions if any property access is attempted
on collections (such as "isset($vec->prop)" and "$x = $vec->prop").

However, there is existing code that uses isset() to check if various
objects have a property with a certain name, and it feels like throwing
an exception here is a little harsh. This diff updates collections to
be tolerant of reading properties.
Clarify contract for DebuggerClient::process and remove confusing returns from helpers.

Functions that always return true may as well return nothing. That is way less confusing.
Clean-up GenericRetDecRefs

This diff cleans some register shuffling that GenericRetDecRefs was
doing because it calls helpers that use a special ABI, in which r13 (a
callee-saved register) is not saved.

The new approach simply checks if r13 is live, and if so, pushes and
pops it around the call. This removes the need for GenericRetDecRefs
to take the function return value as a source.
Don't allow use Foo where Foo is already a class

Classes need to take up space in the alias map (according to zend).

Suprisingly, functions and constants don't. When importing a duplicate, zend doesn't do anything and just continues, and we currently overwrite the symbol. Should I match zend on this, or is the fact that we both continue working good enough?
name in unset error

zend does this, we should too
Add verbose option to test/run

If -v is specified print how to run the test manually even if
it doesn't fail.  Helpful for remembering how to do a
RepoAuthoritative build.
DebuggerCommand::onClient and DebuggerCommand::help do not return anything meaningful.

These commands invariably return true. This is more than a tad confusing to a new reader of the code. Refactor them to return void. Remove a few pieces of dead code that would log something if they ever returned false.
Use eager vmreganchor

This diff introduces a new "eager" vmreganchor, which we call
from some of the heaviest users of vmreganchor. For an eager
reganchor, we save the rbp, pcOff and spOff at the call site
in the MInstrState, and the reganchor itself reads it off
from the MInstrState (instead of following the rbp chain
and looking up the hash table). Currently, the set of functions
which use eager vmreganchor is based on profiling.