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?) -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
