- const correctness fix for AttachStringMode
- document almost all public functions
- move most implementations out of the interface
- rename mutableSlice to bufferSlice
I stopped short of sorting out toNumeric vs isNumericWithVal (I think
we need to delete Variant::toNumeric), and sorting out stuff with the
conversion functions for now.
Reviewed By: bertrand
Differential Revision: D968558
Privatize several public functions, remove some redundant
functions, make some things non-members (appendJSONEscape), remove
DECLARE_BOOST_TYPES, and document contracts; also some gratuitous
style changes. I was initially planning to make it include the null
in its capacity, but since capacity is not exposed anywhere I think
it's fine as is. (And eventually we don't want to require the null
when handing off to String---only when people call data()---but that
is a separate project.)
Differential Revision: D931746
When number_format receives 'null' for one of its separator parameters,
we must pass it back to t_number_format so it can decide whether or not
it should fallback to its default separators.
Currently, when passing NULL to a parameter that is defined as String,
it is implicitly converted to an empty string, and subsequently
str.isNull() will return false.
Instead, we use a Variant with a default string value.
Closes#982
Differential Revision: D940482
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
In HHVM we've been piggybacking resources on the KindOfObject machinery.
At the language level, resource is considered to be a different type than
object, and there are a number of differences in behavior between objects
and resources (ex. resources don't allow for dynamic properties, resources
don't work with the clone operator, the "(object)" cast behaves differently
for resources vs. objects, etc).
Piggybacking resources on the KindOfObject machinery has some downsides.
Code that deals with KindOfObject values often needs to check if the value
is a resource and go down a different code path. This makes things harder
to maintain and harder to keep parity with Zend. Also, these extra branches
hurt performance a little, and they make it harder for the JIT to do a good
job in some cases when its generating machine code that operates on objects.
This diff introduces a new DataType called "KindOfResource", it separates
ResourceData from ObjectData's inheritance hierarchy, introduces a new
smart pointer types called "Resource" and "SmartResource", updates the
runtime as appropriate, and kills some more dead code in ObjectData and
ResourceData. I've tried to keep behavior the same for the most part and
resisted the urge to fix existing bugs with resources.
This is an incremental step towards moving it all the way
to hphp/server. This flattens base but doesn't untangle
the server files from lib_hphp_runtime
C++11 cleanup (clean up easy enums)
This is for runtime/base/... and ended up touching a lot of files
because it turns out we have a lot of reasonably behaved enums.
This stuff almost is an abstraction layer, but it's in a
strange place. Also, the layout of TypedValue isn't something we've
been using through an abstraction layer, and if we want to later I
think we won't want to do so using this one.
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
Removed the litstr overloads of Array::rvalAt, rvalAtRef, lval,
lvalPtr, lvalAt, and set. The main one left to do is operator[].
Fixed a bug in f_get_html_translation_table() where we were copying
the null terminator of what should be a one-character string, thus
creating a two-character string with s[1] == 0. (cc @jdelong)
In class Extension, store a String for the name instead of
const char*. cc @sgolemon
While I was working on the TestCodeRun refactor I found two tests about Tainted code. I looked into it and coulnd't get HHVM to compile with TAINTED=1. Then I checked and none of the extension functions we exposed about tainting were used in WWW. Scratching my head I asked, @srenfro and @jdelong, who thought it was dead. So I killed this zombie.
Post-hphpc, declaring builtins as inline is useless, which obviates the
need for this layer.
This doesn't fully delete the file, because I wanted to keep mindless
parts and use-your-brain parts separate. This is the mindless part. The
remaining functions in noinline.cpp are no-inline wrappers around
(a) a function that isn't defined in an extension, call_user_func_array,
and (b) calling polymorphic is_* functions, which can probably mostly go
away now. But I wanted to exercise more care around those, so they'll
come in a followup diff.
change callers of determine_charset to check for nulls, instead of calling html_supported_charset (to pre-validate charset name) and then calling this (which has to run through a list of names anyway).
The parser depends on zend_html, which means it's impossible
to write parser unit tests without compiling all of hphp. This
separates the pieces that use runtime structures into ext_string, so
the rest can be moved to util/zend. There was a raise_warning call
indirectly from string_html_decode (in determine_charset), but the
runtime use of string_html_decode already checks that it is a
supported charset and otherwise throws NotImplementedException, so I
removed this. Another diff will do the actual move to util.
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