fix yield/await precedence

Summary: cf title.
The diff introduces 2 errors in www: P6377919

Reviewed By: @gabelevi

Differential Revision: D1190948
Platform specific methods of retrieving current thread id

Summary: already had apple/unix path for retrieving thread id
remove syscall include for windows and added
pthreads and windows threads specific versions of getting current thread id

All changes in ifdefs

Reviewed By: @jdelong

Differential Revision: D1458541
Increase stack size limit for cygwin

Summary: Default stack size limit for compiled code for windows is small
windows limits can only be set at compile time (or with some utils that alter pe files, but that's painful)
increase it to the minimum the application expects with the proper linker flag for cygwin

Reviewed By: @ptarjan

Differential Revision: D1458988
getrlimit/setrlimit adjustments for cygwin

Summary: stack size cannot be set on windows (cygwin always returns -1)
although cygwin can have core dump size set (it handles cores through compat layer) other windows cannot
some rlimit values are not available on all systems, check for existence

Reviewed By: @jdelong

Differential Revision: D1458893
Fix Autocomplete damaging incremental mode

Summary: This fixes the behavior of oldify and revive when we have nothing stored at a key.

-If we try to revive on a key than has no old value, we should remove the current value.
-If we try to oldify something that has no value, we should remove the current old value.

Also added missing cache removal when we revive.

I'm not completely sold on relying on revive/oldify for autocomplete/other tools functionality in general. It might be more maintainable (but slower... doesn't seem like the perf hit here would really matter though) to take the classes/funcs out of shared memory and store them when we start, and then put them back when we're done, rather than relying on the good versions being 'one step back' in shared memory.

Reviewed By: @pikatchu

Differential Revision: D1458889
update hhvm-third-party hash to latest
update third-party hash after folly cmake hack to fix build
EZC: fix crash due to EG(exception) being transmitted between requests

Summary: When an exception was thrown from EZC, EG(exception) was left holding a
reference to the smart-allocated exception object, even after the end of
the request. At the end of the request, the object storage was freed by
resetAllocator(), then when zend_wrap_func() was entered in the next
request, EG(exception) would be freed again, causing a crash.

Fixed by installing request event handlers. The requestInit() handler is
analogous to Zend's init_executor().

Closes https://github.com/facebook/hhvm/pull/3121

Reviewed By: ptarjan, joelm

Differential Revision: D1435383

Pulled By: @swtaarrs
Implemented xdebug profiling

Summary: Collecting profiling was implemented in D1423763, enabling/disabling it was
implemented in D1438290, this implements writing the collected profiling info
to a cachegrind compatible file.

The cachegrind file (at least the xdebug version) describes function calls,
function call files, function call time, and function call line #'s.

Programs that read this format (such as kcachegrind, qcachegrind, etc) can
use the generated files to get pretty graphs:
https://www.facebook.com/pxlcld/lqww
https://www.facebook.com/pxlcld/lqwz

One major difference between php5 xdebug and this is that only certain builtin
functions will be collected by the profiler. This is very unfortunate as
profiling builtin function calls would definitely be useful to the user, but
there isn't an obvious fix to this. The profilers plug into
the runtime via event hooks, which are not called for builtin function begin/end
events. Adding this wouldn't be simple because the event hook function begin/end
methods assume an ActRec is generated, which is not true for builtins.
Depends on D1438290.

Reviewed By: @ptarjan

Differential Revision: D1448800
Allow debugger to attach to more classes of requests

Summary: Specifically any request sent with a document root never had
its sandbox setup.  This patch feels like a bit of a hack, but with
just these two lines i can attach to and debug live fcgi request
that i could not without it.

Closes https://github.com/facebook/hhvm/pull/3276

Reviewed By: @ptarjan

Differential Revision: D1457845

Pulled By: svcscm
OS X fixes

Summary: These commits allow compiling HHVM on OS X 10.9 with its native clang compiler.

This also requires https://github.com/facebook/hhvm/pull/3159, https://github.com/facebook/folly/issues/75 and https://github.com/hhvm/hhvm-third-party/issues/18.

CMake config:
```bash
cmake .. \
    -DLIBIBERTY_LIB=$(brew --prefix binutilsfb)/lib/x86_64/libiberty.a \
    -DLIBEVENT_LIB=$(brew --prefix libevent)/lib/libevent.dylib \
    -DLIBEVENT_INCLUDE_DIR=$(brew --prefix libevent)/include \
    -DICU_INCLUDE_DIR=$(brew --prefix icu4c)/include \
    -DICU_LIBRARY=$(brew --prefix icu4c)/lib/libicuuc.dylib \
    -DICU_I18N_LIBRARY=$(brew --prefix icu4c)/lib/libicui18n.dylib \
    -DICU_DATA_LIBRARY=$(brew --prefix icu4c)/lib/libicudata.dylib \
    -DREADLINE_INCLUDE_DIR=$(brew --prefix readline)/include \
    -DREADLINE_LIBRARY=$(brew --prefix readline)/lib/libreadline.dylib \
    -DCURL_INCLUDE_DIR=$(brew --prefix curl)/include \
    -DCURL_LIBRARY=$(brew --prefix curl)/lib/libcurl.dylib \
    -DBOOST_INCLUDE

Closes https://github.com/facebook/hhvm/pull/3182

Reviewed By: @ptarjan

Differential Revision: D1432897

Pulled By: svcscm
Remove unused return type from jmpcond helpers

Summary: That's it.

Reviewed By: @ottoni

Differential Revision: D1457867
Update some HHI files

Summary: Could really do with a false-able type ;)

Closes https://github.com/facebook/hhvm/pull/3283

Reviewed By: @JoelMarcey

Differential Revision: D1460376

Pulled By: svcscm
Changed CRYPT_BLOWFISH to 1 because apparently it is available

Summary: CRYPT_BLOWFISH is set to 0 in HHVM. PHP's documentation states that it is set to 1 where blowfish is available in `crypt`.

Blowfish support is available in HHVM since 4a23fdc0dc804c9a5fa8bc84f9016c1d44597afb so the constant should be set to 1.

Fixes #3274

Closes https://github.com/facebook/hhvm/pull/3284

Reviewed By: @JoelMarcey

Differential Revision: D1460377

Pulled By: svcscm
Add sort_flags to ArrayObject::asort

Summary: PHP's documentation doesn't say anything about this. But they test against it and it works.

Closes https://github.com/facebook/hhvm/pull/3278

Reviewed By: @ptarjan

Differential Revision: D1458888

Pulled By: svcscm
run usercode before ending the request

A previous commit, 15bf01c8f58833733a7337ab975f6aa81105e211, changed
onSendEnd to ignore further output after it was called. This
fixed a failure because a function registered through
register_postsend_function was sending output when the socket was
presumably already closed.

However, onSendEnd is called before hphp_context_exit. The latter
(among other things) executes destructors of live-at-end-of-request
objects. These destructors may execute user code, and are allowed to
send output. This behavior wasn't obvious, because it's hidden behind a
runtime option that is disabled by default (Eval.EnableObjDestructCall).

I initially tried to refactor the way hphp_context_exit works so that
we could first run shutdown handlers, then end our request, and
eventually execute the postsend functions. This requires significant
changes in several places (replacing hphp_context_exit calls, shuffling
the order of execution of things, moving session shutdown location). It
also had the (probably unwanted) side-effect of object destructors
having been called before postsend functions were executed.

We have a circular reference issue, and one of the two mechanisms has to
compromise. In favor of Zend compatibility I propose the following:
- Move things around so they execute in this order:
  onShutdownPostSend > hphp_context_exit > onSendEnd
- Revert the earlier commit, because there's no usercode after onSendEnd
  anymore.

This will prevent FastCGI failures but still allow object destructors to
send output.

There's one caveat:
postsend functions are now able to send output, though technically
post *send* doesn't necessarily mean post *send end*. It's hard to
prevent usercode from sending output, and since this is a facebook/HHVM
specific function I welcome all input on this.