The compile warnings which are explicitly suppressed are:
* -Wno-implicit-fallthrough
* -Wno-unused-parameter
* -Wno-sign-compare
* -Wno-clobbered, only with GCC
Closes GH-5151
Bug 48770 was opened due to conflicting expectations about the behavior of:
call_user_func_array(array($this, 'parent::methodName'), array($arg1,$arg2))
The one reporting the 'bug' seemed to think that since the method name was prefixed with
`parent::`, it should call the method in the superclass of the *class where this code appears*.
However, `$this` might be an instance of a subclass. If so, then it is quite reasonable that
`call_user_func_array` will call the method as defined in the superclass of *the receiver*.
So the 'bug' is not really a bug. Therefore, there is no need for an XFAIL in the tests. They
should just pass.
Amend tests to reflect the actual expected behavior of `call_user_func_array`, not what the
person who reported bug 48770 thought it should be.
Closes GH-5386.
The callable name is provided also if it's not callable, in which
case it's basically "what it would be if it were callable", which
is ClassName::__invoke. The current behavior of casting the object
to string makes very little sense as this will just throw an
exception for most objects.
Little and Big endian files have their own designated folder.
Both use the ASCII charset family.
We may want to add a big-endian/EBCDIC charset family resource bundle in the future.
The build script is currently left untouched as it seems to mostly be for Windows.
Aside from a few very specific syntax errors for which detailed exceptions are
thrown, generally PHP just emits the default error messages generated by bison on syntax
error. These messages are very uninformative; they just say "Unexpected ... at line ...".
This is most problematic with constructs which can span an arbitrary number of lines, such
as blocks of code delimited by { }, 'if' conditions delimited by ( ), and so on. If a closing
delimiter is missed, the block will run for the entire remainder of the source file (which
could be thousands of lines), and then at the end, a parse error will be thrown with the
dreaded words: "Unexpected end of file".
Therefore, track the positions of opening and closing delimiters and ensure that they match
up correctly. If any mismatch or missing delimiter is detected, immediately throw a parse
error which points the user to the offending line. This is best done in the *lexer* and not
in the parser.
Thanks to Nikita Popov and George Peter Banyard for suggesting improvements.
Fixes bug #79368.
Closes GH-5364.
