profileSrcKey() compares the request number with
Eval.JitProfileRequests to decide whether or not the given SrcKey will
be generated in profiling mode. As a result, using profileSrcKey() to
decide whether a given prologue was generated in profile mode or not
was innaccurate: a caller generated in an older request (<
JitProfileRequests) would expect the prologue to be a Proflogue (since
it was JITed beforehand), but the prologue could have been created by
a concurrent, newer request (> JitProfileRequests), which generated the
prologue in non-profiling mode.
This diff fixes the problem by directly checking if the prologue
address is in the profile code section to determine whether it's a
Proflogue or not.
Reviewed By: aravind
Differential Revision: D1141101
DbgAssertRetAddr was useful when I was debugging a specific issue but
I think it's a bit excessive for general use. Don't emit it unless we ask for
extra asserts.
Reviewed By: @bertmaher
Differential Revision: D1140555
There's no case in ir-translator to get here, so this is dead
code. It looks like it was maybe trying to use a LdMem as a guard, so
I'm not going to try to turn this on---we can implement it later.
Reviewed By: @bertmaher
Differential Revision: D1136590
I didn't realize but of course they are generally
implied-nullable right now. (I think we'll eventually want a way to
plumb the nullability through and require things like ?array if it can
be null.) cc @Alite404Exception
Reviewed By: @dariorussi
Differential Revision: D1135647
I think this hasn't shown up yet because nothing has been
getting constprop'd with two inputs of different eval stack flavors.
Reviewed By: @dariorussi
Differential Revision: D1135575
A TODO was to look a the type of bases that aren't inside the
frame. I did this, but then I realized neither of these changes can
kick in yet. The couldBeThisObj needs support for unrelated object
types knowing they aren't related (#3343798), and the mustBeThisObj
will always say false if the base isn't in the FrameThis anyway,
because anything we know about a heap type must include InitNull at
least right now.
We might as well put this in as a test case for #3343798 though. (And
I clarified some comments about how refs work, and fixed something
wrong with BaseR wrt this.)
Reviewed By: @dariorussi
Differential Revision: D1135320
The JIT wasn't really able to use the private property
information from HHBBC, because by the time we saw an AssertT opcode
the property was already extracted.
This diff changes the hphpcType in each class' property info to a new
RepoAuthType struct which can contain both the kind of information
hhbbc can provide as well as what hphpc can provide. Sets the JIT up
to use it, and update prediction-opts to handle the hhbbc case (which
will now generate things like LdMem<Obj<Foo>|InitNull> instead of
LdMem<Cell>.)
A later diff will use the same RepoAuthType flag (plus the repo global
data) to fix the issue with unserialize() being able to break inferred
private property types.
Reviewed By: @ottoni
Differential Revision: D1135298
Many cURL extension tests require an HTTP server to be running
with a specific PHP file available.
Travis will now run this script using the built-in HHVM web server.
I've add skip files so if the user doesn't have the required environment
variable set it will skip the tests, just like PHP does.
Closes#1487
Reviewed By: @ptarjan
Differential Revision: D1117179
Pulled By: @scannell
Added depth as the optional third parameter, there is now no
fixed maximum depth for the JSON parser, default depth is still 512, if
a user specifies a larger depth limit then the various stacks are
resized.
JSON_BIGINT_AS_STRING is now supported alongside the FB collection
options.
Closes#1470Closes#1496
Reviewed By: @ptarjan
Differential Revision: D1117099
Pulled By: @scannell
Done mostly in the parser. There was one weird thing, traits have `self::CLASS` refer to themselves instead of the class that uses them. I had to do runtime support for `parent::CLASS` and `static::CLASS`.
Closes#1096
Reviewed By: @elgenie
Differential Revision: D1129169
What do you think about this? Usually we keep it around anyways in a global variable (`$HTTP_RAW_POST_DATA`) but that is possible to turn off, so we need a fool-proof place to put it to support `php://input`. Before this diff, the code only gave the last packet of the header in libevent and asserted on fastcgi.
Thoughts? I think it is worth supporting as the php docs says
http://www.php.net/manual/en/ini.core.php#ini.always-populate-raw-post-data
... the preferred method for accessing the raw POST data is php://input.
Closes#1557
Reviewed By: afrind
Differential Revision: D1129130
Now that we removed the options from the config files we can remove the options in the code as well
Reviewed By: @jdelong
Differential Revision: D1135707
- This mostly just moves stuff around. The idea was to put everything that is f_mysql_ in ext_mysql and move everything else into mysql_common
- It also breaks up the query function into two parts because I need it for mysqli
- Doing the query
- And getting the result part
Reviewed By: @ptarjan
Differential Revision: D1106027
There's one test case that's giving me fits in trying to implement Call,
and if we were just codegen'ing these opcodes, the problem would just go
away. So here they are.
StLoc happens to be third most frequent punt. CheckStk forced me to get
the jump-chaining machinery working, and it's surprisingly simple.
Reviewed By: @ottoni
Differential Revision: D1136517
Persistent connections currently return a cached connection for (key = "hostname").
Expected behavior is to return a cached connection for (key = "hostname + port").
As a result, persistent connections write and read from the wrong socket if you have multiple connections to the same hostname but different port.
Redis hhvm implementation is affected by this bug (probably other modules too, but not MySQL at least, who uses its own socket cache handler).
Closes#1599
Reviewed By: ps
Differential Revision: D1135971
Pulled By: @scannell
std::list is inconvenient for three reasons:
1. when splitting, we have to iterate to find the split position
even though we already have the interval we care about.
2. Loops that visit each split interval must do work for the
parent, then a separate loop for the child.
3. we never need the "prev" pointers
A plain 'next' pointer (aka intrusive singly-linked list) solves
all three problems.
Reviewed By: @bertmaher
Differential Revision: D1135956
In trying to implement codegen for the Call opcode, I'm running into
problems with the differences between ARM and x64's calling conventions,
specifically with regard to how they save return addresses.
Until now, our ARM code hasn't been treating the link register (the
return address register) like it's supposed to be treated. The register
is technically caller-saved, but normal ARM programs (such as C programs
compiled by gcc) don't save and restore it around callsites. Instead,
non-leaf functions just save it at the very beginning and restore it
just before returning, simply as part of setting up and tearing down the
frame.
What this means for us is that we're now saving it on the stack
immediately on entry to the TC, since, viewed through the traditional
calling-convention lens, the entire TC is a non-leaf function. This
means that we no longer need to save/restore around host calls.
Reviewed By: @edwinsmith
Differential Revision: D1133438
Summary: This splits the larger Travis test runs roughly evenly to
increase the chance that the tests will pass before hitting the timeout.
Reviewed By: ptarjan
Bytecodes that resolve strings to a class or a function need to normalize the string so it never starts with '\'
Reviewed By: @jdelong
Differential Revision: D1135085
Also, change the default size to match cli.hdf, so we don't
do a resize on command line scripts.
Reviewed By: @edwinsmith
Differential Revision: D1126293
This has been disabled since shortly after it was added,
since hphpc doesn't handle exception edges correctly and reports wrong
information.
Reviewed By: @swtaarrs
Differential Revision: D1135310
Quite a while back I perflabbed turning this off and saw red,
but I think it must've been noise. I ran perflabs with an
always_assert(0) in applyInputMetaData here and it never triggered.
Reviewed By: @edwinsmith
Differential Revision: D1133071
Added warnings to match Zend behavior for incorrect number of arguments passed
and for not passing an object as the first parameter when reflecting on instance properties.
Reviewed By: @ptarjan
Differential Revision: D1135118
I thought 86pinit could only set private properties to
uncounted types, but there's also collection literals. Merge in
TInitCell---in these classes all private properties initialized by
86pinit will end up as TCell for now, since they start as uninit in
the scalar initializer. (Things with non-scalar initializers also
will be TInitCell.) We'll make it do better later.
Reviewed By: @dariorussi
Differential Revision: D1135293
I've hit this once or twice, and I think it probably is a
race in hphpc or something (it is not consistent). Just add some
logging to try to help debug next time. (So far it's always
Ix-related closure classes that have AttrUnique but actually aren't in
the cores I've had.)
Reviewed By: @swtaarrs
Differential Revision: D1135290
Guilherme Ottoni