- boost::shared_ptr now has "explicit operator bool", which means we
can't "return <a shared ptr>" from a function with return type bool.
- Our use of shared_ptr<T[]> in debugger_client.h was screwed.
Unfortunately it's not straightforward to make it a unique_ptr as per
our discussion; there are other objects that call setLiveLists, and
it's not clear to me that this is a total transfer of ownership. I'm
just fixing the immediate problem using shared_array. (Also made the
typedef less confusing, hopefully.)
- Our specialization of graph_traits<G> for ControlFlowGraph didn't
define the null_vertex member function. This didn't matter in older
versions of boost because they didn't use it internally, but now they
do (the call to depth_first_search in control_flow.cpp was failing to
compile).
I was learning from @jdelong and he said that you should use
double quotes for local includes and angle brackets for library
includes. I asked why our code was the way it was, and he said he wanted
to clean it up. I beat him to it :)
Conflicts:
hphp/runtime/base/server/admin_request_handler.cpp
hphp/runtime/vm/named_entity.h
After some recent cleanup to generators, local analysis was
able to remove some stores that it shouldnt have done, because
it didnt take account of the fact that the locals were
generator parameters.
Alias manager does not know whether generator parameters are passed by
reference. This didn't matter, because every generator had at least one
function call (hphp_continuation_done()) that pretty much disabled unused
variable elimination.
This diff fixes that, lets us get rid of artificial function calls in
generators and will allow later improvements in alias manager.
This basically targetted symbols.php, and Globals, but ended up
killing a lot more. I could keep adding more and more, but
this seems like a good point to stop and continue with
another diff.
g++-4.7.1 treats "FOO"bar as a c++-11 literal operator, even
if bar is a macro with an expansion such as "BAR" - so add a space
after the quote (this seems like a bug, and I fixed a bunch of these
a while ago, but we just added a slew of PRI*64 macros which break
under 4.7.1).
Also, it warned that "explicit by-copy capture of 'this' redundant"
for a lambda declared [=, this] - so I removed the this.
We also needed more than the 60 levels of template expansion that was
allowed by the makefile.
Per @mwilliams' suggestion, this is the first stage in a staggered approach to replacing int64 with int64_t. More precisely I inserted "typedef ::int64_t int64;" in util/base.h and dealt with the consequences.
This change is mostly for FB internal organizational reasons.
Building is not effected beyond the fact that the target now
lands in hphp/hhvm/hhvm rather than src/hhvm/hhvm.
Tim Starling