parser and codegen changes for XHP spread operator
Summary:
HHVM parses XHP creation as if it were actually a `new xhp__foo_bar(...)` call. We need to augment the attribute array to include consecutively numbered spreads (so the array keys are unique and the runtime can properly expand each spread), which requires a small stack of ints every time we descend into a new XHP while parsing an attribute list. In practice, it doesn't really offer much value to spread an XHP literal, because one could have just written the attributes manually in the first place, but there's no reason to disallow such constructs.
There is some very special cases in the lexer state machine to figure out if we are in an XHP tag or not (which triggers different token emission), so I had to allow for `{` as the next token for identifying XHP state.
Reviewed By: paulbiss
Differential Revision:
D6326686
fbshipit-source-id:
e146097f317bb711ff157a3201908e12328f097f