| commit | e00f4d9e8836eacfd29b29e844dc9c8bed9fdcd2 | |
| author | Daniel Neiter <dneiter@fb.com> | |
| Thu, 25 Jun 2020 00:56:37 +0000 (24 17:56 -0700) | ||
| committer | Facebook GitHub Bot <facebook-github-bot@users.noreply.github.com> | |
| Wed, 1 Jul 2020 01:11:49 +0000 (30 18:11 -0700) | ||
| tree | e9e26ca4fc63f2cf2f77a5d5c95aafeb8f1fde2f | treesnapshot (tar.gz zip) |
| parent | 5ae78a0bb6fada9844b9e64402b000b768788c46 | commitdiff |
HHVM support for HH\is_vec_or_varray() and HH\is_dict_or_darray()
Summary:
We've decided, that we want to expose HH\is_vec_or_varray() and HH\is_dict_or_darray() primitives now, that varray and darray are distinct runtime types.
This diff adds HHVM support. I'll put up typechecker support (to refine the argument) in a separate diff. For now, just add them into hhi.
Unlike other is_*** functions, I added HH\is_vec_or_varray() and HH\is_dict_or_darray() as standard builtins, not builtins-which-get-emitted-as-special-bytecodes. We can revisit it, if these functions become hot, but for now adding bytecodes for these functions seems an overkill to me. Let me know, if anyone feels strongly otherwise.
I added cls_meth compatibility logging into is_vec_or_varray(), but nothing else - I don't think we need any other logging in there (e.g. none of the HAM logging).
Differential Revision: D22200598
fbshipit-source-id: 65ce3a9f4dfef98cb6ca796b24badc27713481bf
Summary:
We've decided, that we want to expose HH\is_vec_or_varray() and HH\is_dict_or_darray() primitives now, that varray and darray are distinct runtime types.
This diff adds HHVM support. I'll put up typechecker support (to refine the argument) in a separate diff. For now, just add them into hhi.
Unlike other is_*** functions, I added HH\is_vec_or_varray() and HH\is_dict_or_darray() as standard builtins, not builtins-which-get-emitted-as-special-bytecodes. We can revisit it, if these functions become hot, but for now adding bytecodes for these functions seems an overkill to me. Let me know, if anyone feels strongly otherwise.
I added cls_meth compatibility logging into is_vec_or_varray(), but nothing else - I don't think we need any other logging in there (e.g. none of the HAM logging).
Differential Revision: D22200598
fbshipit-source-id: 65ce3a9f4dfef98cb6ca796b24badc27713481bf