On 11/21/2015 10:19 AM, Guillaume Munch wrote: > Le 20/11/2015 19:43, Georg Baum a écrit : >> Scott Kostyshak wrote: >> >>> I was hoping the recent commit fixing regex issues would fix the >>> failing >>> test (test_biblio) of 'make check'. I just wanted to confirm that the >>> test fails for others on current master also. >> >> It does. The reason is that the output of escape_special_chars() changes >> when compiling with std::regex. The attached patch would fix the test >> for >> std::regex, but then make check would fail when using boost::regex. > > Of course, the source should be corrected, not the test. > > BTW I read the new documentation for tests and it did not help me at > all. It said nothing for "make check", and when I run "make check" it is > still a mystery to me where I can get any log file that says what went > wrong. (The file test_biblio.log is always empty.) > >> >> This shows that the regex engines we use do still interpret the >> expressions >> in different ways, and I believe I also know the reason: The expressions >> have changed to ECMAScript syntax, but the boost::regex engine does not >> default to ECMAScript, but to boost perl style. > > But "perl" for Boost is just a synonym for "ECMAScript", and the > difference between std and boost in the current master is only > supposed to be a few perl extensions added. (See > <http://www.boost.org/doc/libs/1_57_0/libs/regex/doc/html/boost_regex/ref/syntax_option_type/syntax_option_type_perl.html>.) > > > Therefore the problem is probably still in the expressions. What I > understand from your patch is that the output in std::regex is still > wrong: the regex adds \\ instead of \. The result of the test you showed > with the patch. I am worried by the line: > > return lyx::regex_replace(expr, reg, "\\\\$&"); > > This should be: > > return lyx::regex_replace(expr, reg, "\\$&"); > > but then this would no longer work with Boost, because it interprets the > backslash as an escape sequence... This appears to be a bug in Boost: > > format_default: Specifies that when a regular expression match is to > be replaced by a new string, that the new string is constructed using > the rules used by the ECMAScript replace function in ECMA-262, > ECMAScript Language Specification, Chapter 15 part 5.4.11 > String.prototype.replace. (FWD.1). > This is functionally identical to the Perl format string rules. > > But the "Perl format" treats backslashes as a character one must escape, > which contradicts the preceding sentence. > >> Therefore, we do now have >> exactly the inverted situation than before dbce5cafcc167: regexes are >> interpreted correctly when using std::regx, but not when using >> boost::regex. > > On my side master still works fine with Boost so I don't see an inverted > situation. But, if we did the correct thing and changed the format > string to \$& as it should be, we would indeed end up in a symmetric > situation. > >> >> What needs to be done now is to call boost::regex in ECMAScript mode. >> Then >> escape_special_chars() will produce the same output for both regex >> engines. > > As I understand, both are already set to ECMAScript, the problem being > that Boost does not implement ECMAScript. > >> What I am not 100% sure yet is whether it is correct, there seem to >> be too >> many backslashes. > > I am afraid that for now there are only two unpleasant solutions: > * fix this particular replacement using a hack, or
I think we have used conditional compilation for such things in the past. Ugly in the source, but it works. > * use Boost on every platform until we can get rid of it entirely. I'm guessing people will not like this option, but it would also work. Richard
