Front page | perl.perl5.porters |
Postings from February 2017
On 01/25/2017 09:15 PM, Karl Williamson wrote: > On 01/23/2017 06:08 AM, hv@crypt.org wrote: >> Dave Mitchell <davem@iabyn.com> wrote: >> :I've always been very dubious about trying to continue parsing generally >> :after an error has been encountered. We've spent years trying to fix all >> :the bugs and SEGVs that this causes. >> : >> :I've rarely found the extra error messages it produces useful: in both C >> :and perl I tend to just look at and fix the first error reported, then >> :recompile. Long gone are the days where you would have to wait >> minutes to >> :recompile a source file (or wait for a compile report to be posted >> back to >> :you from the Data Centre). >> : >> :I'd be interested to hear opposing opinions or counter-examples though. >> >> I quite regularly find more than one error message useful when I've just >> added or changed a largish swathe of code (maybe 50-200 lines). That's >> usually a bunch of simple mechanical errors such as typos and missing >> semicolons. >> >> In most cases even so it would not be a problem to get those one at a >> time, >> but at a previous $workplace most of the code could not be run or even >> compile-tested on the same system where the revision control system could >> run, nor easily even on the target system without complex setup. >> >> So it was either an scp + app-restart cycle (around 60s turnaround) for >> each edit, or for slightly faster turnaround edit on the target system >> and then risk failing to correctly duplicate those changes onto the >> source >> system for commit. >> >> I recognise that that was a deeply suboptimal setup; I don't know how >> widespread similar setups might be though, or to what extent we should >> try to cater for them. >> >> Hugo >> > > For the immediate issue at hand, I suggest we create a new > PL_inpat_errors variable that is either a boolean or a counter of errors > that were found in patterns. Then the regex parser would parse unless > that was set. > > One of the issues is re-parsing. One expects in the regex compiler a > certain amount of sanity in the input. This would allow more instances > of continued parsing after an error, without reparsing something insane. > This has now been done, differently, by 7c449856260e14be9e73a4060cb86a5e2f680a65. If a parse error is found, a flag is set for the pattern in question. When it comes time to compile that pattern, doing so is skipped if the flag is set. Thus the program can continue to be parsed for more errors, but we avoid reparsing something known to be problematic.Thread Previous