Preprocessor: Don't allow unclosed extension tags (matching until end of input)
authorBartosz Dziewoński <matma.rex@gmail.com>
Tue, 24 Nov 2015 21:55:24 +0000 (22:55 +0100)
committerTim Starling <tstarling@wikimedia.org>
Thu, 21 Jan 2016 04:22:34 +0000 (04:22 +0000)
commitf51d0d9a819f8f1c181350ced2f015ce97985fcc
tree2469b45587817edee48086cb94f99f3aff5074bb
parent639cecb4bec8ac275d2c5eac089a124ccf96d7c4
Preprocessor: Don't allow unclosed extension tags (matching until end of input)

I think it's saner to treat this as invalid syntax, and output the
mismatched tag code verbatim. The current behavior is particularly
annoying for <ref> tags, which often swallow everything afterwards.

This does not affect HTML tags, though. Assuming Tidy is enabled, they
are still auto-closed at the end of the page content.

Related to T17712 and T58306. I think this brings the PHP parser closer
to Parsoid's interpretation.

It reduces performance somewhat in the worst case, though. Testing with
https://phabricator.wikimedia.org/F3245989 (a 1 MB page starting with
3000 opening tags of 15 different types), parsing time rises from
~0.2 seconds to ~1.1 seconds on my setup. We go from O(N) to O(kN),
where N is bytes of input and k is the number of types of tags present
on the page. Maximum k shouldn't exceed 30 or so in reasonable setups
(depends on installed extensions, it's 20 on English Wikipedia).

To consider:
* Should we keep previous behavior for unclosed <includeonly> /
  <noinclude>? This would be particularly disruptive for these if
  someone relied on the old behavior, and they're already
  special-cased in places.
* Unclosed <pre> tags are now treated as HTML tags, and are still
  displayed as preformatted text, but without suppressing wikitext
  formatting.

Change-Id: Ia2f24dbfb3567c4b0778761585e6c0303d11ddd0
includes/parser/Preprocessor_DOM.php
includes/parser/Preprocessor_Hash.php
tests/parser/parserTests.txt
tests/phpunit/includes/parser/PreprocessorTest.php