This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines in all
*.phpt sections.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch simplifies line endings tracked in the Git repository and
syncs them to all include the LF style instead of the CRLF files.
Newline characters:
- LF (\n) (*nix and Mac)
- CRLF (\r\n) (Windows)
- CR (\r) (old Mac, obsolete)
To see which line endings are in the index and in the working copy the
following command can be used:
`git ls-files --eol`
Git additionally provides `.gitattributes` file to specify if some files
need to have specific line endings on all platforms (either CRLF or LF).
Changed files shouldn't cause issues on modern Windows platforms because
also Git can do output conversion is core.autocrlf=true is set on
Windows and use CRLF newlines in all files in the working tree.
Unless CRLF files are tracked specifically, Git by default tracks all
files in the index using LF newlines.
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
