This implements a reduced variant of #1226 with just the following
change:
-Fatal error: Uncaught exception 'EngineException' with message 'Call to private method foo::bar() from context ''' in %s:%d
+Fatal error: Uncaught EngineException: Call to private method foo::bar() from context '' in %s:%d
The '' wrapper around messages is very weird if the exception
message itself contains ''. Futhermore having the message wrapped
in '' doesn't work for the "and defined" suffix of
TypeExceptions.
TypeException stays as-is for now because it uses messages that are
incompatible with the way exception messages are displayed.
closure_038.phpt and a few others now show that we're generating
too many exceptions for compound operations on undefined properties
-- this needs to be fixed in a followup.
As we discussed with stefan, we think previous of allowing use with
classes is a bug, should be forbided, anyway, the error message should
be improved.
# The handling of private properties in classes is now consistent with private properties in traits.
# Perviously, privates could cause strict warnings, are were not properly merged into the class when
# the parent class had a private property of the same name. Now, we introduce it without notice,
# since it is a new and independent property, just like in normal classes.
# This problem was diagnosed while working on Bug #60536.
- aliases that are not actually matching anything are treated as errors now. This
will make sure that all methods that are expected to be in a class are actually
there, or in case a trait changed for instance, that the code breaks already
on composition
- Precedence declarations are also checked to ensure that the method
which is supposed to take precedence actually exists, however,
the other traits mentioned in the declaration are not regarded.
We are more lenient here, since this avoids unnecessary fragility.
- fixed another seamingly unrelated test which broke in the progress
but wasn't clear before either.
# Moved the freeing of overriden functions to a point after the check.
# The new check comes after the normal inheritance check to give the first check
# the opportunity to abort with a more detailed error.
# Also fixed a small type in an unrelated test.
# The handling of legacy constructors defined by traits was corrected.
# They are now properly registered and used on instantiation.
# The situation for conflicting legacy and __construct constructors is
# mostly identical. If they are defined in the class, they override conflicts
# and do not collide. However, in case different styles are mixed, between
# class and trait definition, we assume a programmer's mistake and report
# a collision.
#
# BTW: +1 for all the fixed tests! `make test` is fun again.
# The method got unconditionally deleted from the class, since it was assumed that we override it, but we did not in case of abstract methods coming from a trait. Thus, dont delete when we try to merge in an abstract method.
# __TRAIT__ behaves like __CLASS__ more or less but is constraint to traits.
# Since traits are not types, there are not many valid use cases, and trying
# to use __TRAIT__ to make traits more like classes is discouraged.
# Bug was uncovered by discussion in http://news.php.net/php.internals/54129
# Forgot to check the actual value of the initializer comparison, only checked
# whether comparison was successful which is not enough.
- missed a failing Traits test, but is now fixed, and the bug covered by a dedicated test
# Should always comment conditions that go over more than two lines :-/
#This change is made to have all possible cases of collisions consistently handled as fatal errors.
#The reason to have it fatal is that most likely something changed unexpectedly and needs urgent attention by the developer, since it will fail eventually anyway for instance because the expected method is missing in the class.
#Discussed in this thread: http://marc.info/?l=php-internals&m=129155790226876
#Please review this change, I moved the routine which copies statics from the closure code to zend_variables.c
#Please also have a look to check whether the TSRMLS_DC is correct, and whether it fits with the rest in zend_variables, because there you are using some macro magic and I am not exactly sure what the reason is for that.
