Create test.txt

test travis
Merge branch 'master' of https://github.com/nareshv/hhvm
enable fast_finish on travis

hvvm requires a lot of travis resources to run the CI builds. travis supports a fast_finish switch which cancels all jobs related to a built when the first job errors.

see http://blog.travis-ci.com/2013-11-27-fast-finishing-builds/
Add support for all request methods sent via fastcgi

Added support for request method to be passed in from apache/nginx.
Added access log support for the above request methods.

Closes #1876
Closes #1831
Closes #1885

Reviewed By: @fredemmott

Differential Revision: D1200544
only use one threadlocal for datetime

@markw65 says this should be the pattern

Reviewed By: @fredemmott

Differential Revision: D1201148
XLS: Fixes & clarifications

This reworks XLS to work more clearly, (I hope) handle edge
cases more obviously, ensure live ranges are open-ended
ranges, and allow use-positions to be just past the end of
their live ranges.

Reviewed By: @jdelong

Differential Revision: D1145927
Move PersistentObjectStore out of execution-context.h

Also document it minimally.  Also, rename it to
PersistentResourceStore now that Resources aren't Objects.

Reviewed By: @ptarjan

Differential Revision: D1198283
Remove macros for debugger settings

Sometimes a struct with public members is just fine.
Auto-generating read/write accessor methods is a pretty good sign
there's not actually any encapsulation going on ...

Reviewed By: @ptarjan

Differential Revision: D1198287
Remove unnecessary HPHP:: prefixes in execution context

Reviewed By: @edwinsmith

Differential Revision: D1198293
add jackalope-jackrabbit to the tested frameworks

Fixes #1980

Reviewed By: @ptarjan

Differential Revision: D1201748

Pulled By: @fredemmott
Add some CGetM base types to stats

Probably a few more things like this will be interesting, so
add a visitor that has access to the interpreter types.  For now it
just has a TypeState for CGetM with a few bases.

Reviewed By: @edwinsmith

Differential Revision: D1198224
Remove the NewArray opcode

This never happens as output from emitter.cpp in repo
authoritative mode, so we can just encode it as a NewArrayReserve with
a particular size.  Follow-up diff renames NewArrayReserve to
NewArray.

Reviewed By: @edwinsmith

Differential Revision: D1198240
Rename NewArrayReserve to NewArray

Reviewed By: @edwinsmith

Differential Revision: D1198241
Make Bytecode comparable and hashable

Had to add this for something I was experimenting with, but
it seems worth peeling out on its own.  The hash function is probably
pretty bad but could be improved later if we end up actually
using it.

Reviewed By: @edwinsmith

Differential Revision: D1198654
Refactor the hhbbc interpreter functions for better modularity

The per-opcode abstract interpreter code was getting too
large to reasonably be in a single file.  Getting minstr stuff out on
its own seemed overdue, and all the helpers (popC(), etc) could also
go somewhere else.  Later we might even want to separate out a few
other groups (e.g. arithmetic: the type-arith functions have no way
right now to indicate when something is nothrow, but I was definitely
not going to add them to the InterpStepper class just to allow that).

This is a long commit message, but reviewing the rationale is probably
more relevant than reviewing the code.

I considered the following solutions:

  - 1. Leave it all in a class, but define different functions in
    different .cpps.  (I started down this path and then threw it
    away.)

  - 2. Still have one translation unit, but #include different
    sections from different files.

  - 3. Make everything non-members, but use macros to make a mini-DSL
    for accessing state that still works with implicit parameters.
    (Define opcode functions with something like IOP(CGetM) {}, etc.)

The main problem I have with #1 is that it increases the friction for
adding helper methods.  In HHBBC the total code size is still pretty
small, so it's not a huge deal to recompile everything when you change
interp.h.  But this doesn't scale, and elsewhere in the codebase where
we have objects with one method per bytecode I think the increased
penalty to adding helpers has increased function size, so this is a
problem worth thinking about more generally.  (In particular, if you
want to add a helper to bytecode.cpp, you often have to declare it in
a header that will cause you rebuild the whole world.  See #3834388.)

The #2 idea seems plausible, but weird.  Its impact on build times is
hard to predict (and might even be good in some cases), but its impact
on implementation hiding is negative: you can't declare helpers in an
unnamed namespace and be sure they are private.

The #3 one bothers me because it seems really unfortunate to define
names like "popC" in ways that don't respect scope.  A few of them are
plausibly identifiers you might want to have active for more than one
purpose in some of these files.  The cost of passing "env" everywhere
(a common idiom in ML) seems arguably lower than that.  It seems
plausible that there may be some cases where this option is
preferable, though.

After starting down the path of #1, and then some thinking, I'm of the
opinion that putting all the methods in the same object isn't really
providing us the intended benefit in cases like this.  It seems that
the reason you want to put methods like this in the same class is so
you can declare some of the state private, and hide it from the rest
of the program.  However, in cases like this (or bytecode.cpp), member
accessibility is not really being used to provide an abstraction
layer.  And for hiding methods, you get much better hiding if you can
declare them local to .cpp files instead of private to a class.

So the solution I ended up with is to just pass a parameter to each
method manually.  This means any function can be defined in any
translation unit that we want.  Also, data hiding is actually not any
worse than the class approach: the interpreter functions can still
only modify versions of the state that they are given access to (by
actually passing it a pointer), which was exactly the state they had
access to before this, since these structures live on the stack and
can't be reached any other way.

One detail specific to this diff: there is a family of instructions
with special additional state (the minstr instructions), but they need
to call all the generic functions as well (popC, locAsCell, etc).
This diff implements this by making the minstr environment struct a
subtype of the general interpreter environment, so you still pass a
single state object everywhere, and it's legal to call popC(env) when
`env' is a minstr env.

Reviewed By: @edwinsmith

Differential Revision: D1200426
Miscellaneous aarch64 compilation fixes

Miscellaneous fixes while trying to compile on aarch64.

Reviewed By: @sgolemon

Differential Revision: D1200987
Fix assertion in memory-manager.cpp

It turns out that a jemalloc sync can occur between the initialization of the MemoryManager and when refreshExternalStats is called during hphp_session_init to erase the record of shared structure initialization. This breaks multiple assumptions, so disallow syncs until we really do want to start tracking. This refines the related assertions as well.

Reviewed By: @edwinsmith

Differential Revision: D1198787
Remove CMake/FindBoost.cmake

Having our own custom module wasn't really giving us anything,
and it's causing issues with particularly new versions of boost.

Let the local cmake supply FindBoost.cmake

Closes #1291
Fix multiple declarations of the same static variable in closures

If there are multiple StaticStatements with initialization in a closure,
multiple entries for the same static variable are created in the
Func's m_staticVars table, breaking this closure assertion:

hhvm: hphp/runtime/ext/ext_closure.cpp:59: void HPHP::c_Closure::init(int, HPHP::ActRec*, HPHP::TypedValue*): Assertion `numDeclProperties - numArgs == m_func->numStaticLocals()' failed.

Reviewed By: @jdelong

Differential Revision: D1202452
Fix bug with c_Vector::getImmutableCopy()

In some cases c_Vector::getImmutableCopy() calls objMallocLogged() to
allocate 0 bytes, which is wrong. This diff fixes the bug.

Reviewed By: @elgenie

Differential Revision: D1203592