On Aug 15, 2008, at 5:18 AM, Dag Sverre Seljebotn wrote: > Dag Sverre Seljebotn wrote: >> Robert Bradshaw wrote: >>> On Fri, 15 Aug 2008, Greg Ewing wrote: >>> >>>> Dag Sverre Seljebotn wrote: >>>> >>>>> So I propose this change: There is a cutoff in the pipeline at >>>>> which >>>>> stage errors are reported (and if any, processing stops). >>>> That sounds reasonable. You could even go further and have >>>> a cutoff after every stage of the pipeline, so that any >>>> stage can assume it has valid data from the previous stage. >>> Often it is useful to maximimize the number of errors caught in a >>> single >>> invocation of the compiler. One thing I hate doing is (run the >>> compiler, >>> fix the only reported error) x 10. >>> >>>> A refinement would be to have "fatal" and "non-fatal" >>>> errors, where fatal errors terminate compilation at >>>> the end of the current pipeline stage. >>> This sounds like a very good idea. Non-fatal errors would result >>> in a >>> valid tree that could be carried on to the next stage, but invalid >>> compilation. >>> >>> It might be to hackish, but we could also run each stage in a try- >>> catch, >>> and if it catches any Exceptions after a "non-fatal" error it >>> silently >>> ignores them. >> >> I already did this :-) sort of, but non-fatal error might very well >> require that processing continues within the transform. The >> current system >> is that transforms can raise a CompileError if processing cannot >> continue, >> or call self.context.nonfatal_error(CompileError(..)) if they just >> want to >> report an error and let the execution thread move on. >> >> It seems too much to add yet another mechanism to abort just a single >> transform (you just use a try-except clause in __call__ to drop >> out of the >> transformation stack and report the error as nonfatal before >> returning). >> >> So I'll just add a pipeline step that checks the nonfatal error >> list and >> stops compilation if there were nonfatal errors (prior to code >> generation). One can drop out before this by raising a >> CompileError and >> let it go all the way up to the pipeline runner. > > OK I now have an implementation of this. > > The problem is that there are a lot (around 40) instances of error > being > called in the code generation phase for various illegal condition. > > I'd argue that these should be checked for before code generation, so > that code generation can assume everything is OK. That should make for > cleaner code. > > But I'm not sure whether to move forward with this now. It's in -dagss > anyway, but may not hit -devel. (It breaks some testcases which tested > for more than one error, if some of those errors are reported during > code generation.) > > So, the quick options for making the beta stop crashing seems to be: > - Make SwitchTransform handle the error case gracefully. > - Push my change and don't care about the regressions in the error > tests > (alternatively split them up or move just the error reporting that > breaks from code generation to analysis or a visitor) > > I might pick one of these eventually but need to go on with "my own > stuff" as well. (There will be some warning/a vote before a > release, right?)
I just wrote a simple one at http://hg.cython.org/cython-devel/rev/ b1516f6bf662 . It's much less invasive, and doesn't break any of the current error reporting. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
