The primary goal here: move the custom overloads for `hphp_raw_ptr` of static/dynamic cast in `Base.h` out of the boost namespace, into HPHP namespace (which already uses normal boost versions). This means all casting, to be consistent, should happen in the HPHP namespace
Differential Revision: D959867
Incrementally renaming foo_bar.* to foo-bar.*. runtime/vm
is nearly done, getting started on runtime/base. This does
a dozen or so files, will do more in separate diffs.
Differential Revision: D910489
StringData::getPrecomputedHash was unused. The
isValidVariableName thing was a thin wrapper on a zend function that
is hardly used, and it shouldn't be a member function anyway. The
convert_double_helper and convert_integer_helper also shouldn't be
member functions, and the former duplicated buildStringData(double)
too much for me so I removed it.
Differential Revision: D903915
The problem was a few:
* All constant declarations were wrapped in a statement list. The merge-only check was allowing top-level `define()`s but not top level statement lists. I unwrapped them. I have no idea why it was done. Probalby just cargo cult programming.
* When converting a UnitEmitter to a Unit we only allowed constants in RepoAuthoritative mode and not systemlib mode.
* Systemlib constants weren't being set as UnitMergeKindPersistentDefine
* UnitMergeKindPersistentDefine constants weren't being marked mergeOnly when pulling out of a repro
Throws the aliased class into a target cache slot for the new
name. Handles errors when you try to re-alias a class, but doesn't
restrict a few other cases zend does:
- If you implement an interface twice, zend complains (one of the
alias tests checks this). I tried turning it on, but we violate
it in systemlib currently so I left it off.
- class_alias_014.php does some namespace stuff I don't quite grok.
(@ptarjan let me know what to do if it's easy).
- inter_007.php uses class_alias, but is testing a warning that
happens even with out it. (We don't raise this warning.)
- zend raises a warning if you try to class_alias a non-user-defined
class; I left this out.
When we see `define('Foo', 'Bar')` in a namespace, we don't know if it is talking about the global define function or the a local namespace one. What should we do? Does marking constants Dynamic that aren't actually dynamic break anything? Without this, HPHP creates a creates a CodeError.js
Closes#771
This code was using the old assumption that namespaced functions always started with a ##\##. Instead, lets do the same thing we do in the emitter.
Closes#771
we don't store constants with the preceeding ##\## so slice it off. I originally edited ##name## but couldn't find a clean c++-ish way to do that. I'm open to teachings.
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
It turned out a lot of the namespace stuff still worked. The biggest thing for the first pass is that we don't fallback to the global function or constant if there isn't a namespaced one.
Also, when a constant has a ##\## anywhere in it it throw an error when it isn't defined, instead of assuming the string.
A constant defined in a function/method should be treated as
dynamic.
A class constant with a dynamic initializer should evaluate to
the value of its initializer at the time the constant was first
seen; so the optimization should be all or nothing - either
turn the class constant into a scalar, or leave it in its original
form.
It was only used to fold SimpleFunctionCall nodes. Ive setup enough
of the runtime that we can call invoke (which goes through hhvm's
normal Func dispatch), and then removed it.
This diff suppresses the output of C++ for the "pure" classes defined in
system/classes, and it rips out all the uses of MethodCallPackage (except
for the i_* and ifa_* helpers, which we can go after separately).
Also cleans up a bunch of "if (hhvm)" and "#ifdef HHVM" checks in builtin_functions.cpp,
systemlib.cpp, object_data.cpp, and class_info.cpp (and the corresponding .h files).
Note that this does not completely remove the generated C++ files. We
still generate code for the PHP files in "system/globals" and we still
generate the g_class_map (because the VM needs g_class_map at startup
when it creates Class's for the extensions). We also still have the
dynamic_func_table/dynamic_class_table stuff, MethodCallPackage, and
the i_* and ifa_* helpers to support invoke_builtin() (which is still
used by the compiler).
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.
Jordan DeLong