On Sat, Feb 19, 2011 at 12:52:38PM -0800, Robert Bradshaw wrote: > On Sat, Feb 19, 2011 at 11:35 AM, W. Trevor King <wk...@drexel.edu> wrote: > > On Thu, Feb 17, 2011 at 03:53:13PM -0800, Robert Bradshaw wrote: > >> On Thu, Feb 17, 2011 at 3:12 PM, W. Trevor King <wk...@drexel.edu> wrote: > >> > * Extending class cdef/cdpef/public/readonly handling to cover enums, > >> > stucts, and possibly unions. > >> > >> This seems like the best first step. > >> > >> > Problems with me getting started now: > >> > > >> > * I don't know where I should start mucking about in the source. > >> > >> ...The other files to look at would be Parsing.py,.. > > > > I've got the the Parsing pretty much working, but portions of the test > > suite are now failing with things like > > > > === Expected errors: === > > 1:5: function definition in pxd file must be declared 'cdef inline' > > 4:5: inline function definition in pxd file cannot be 'public' > > 7:5: inline function definition in pxd file cannot be 'api' > > > > > > === Got errors: === > > 1:5: function definition in pxd file must be declared 'cdef inline' > > 4:12: inline function definition in pxd file cannot be 'public' > > 7:5: inline function definition in pxd file cannot be 'api' > > > > while cythoning tests/errors/e_func_in_pxd_support.pxd: > > > > cdef foo(): > > return 1 > > > > cdef public inline foo2(): > > return 1 > > > > cdef api inline foo3(): > > return 1 > > > > The current Cython implementation does not consider 'cdef' to be part > > of the node code, and my current implementation does not consider any > > qualifiers to be part of the node code. > > > > It's unclear to me what the "right" position is for the start of a > > function (or variable, class, ...) should be, or how errors should be > > formatted. My initial impression is that Node.pos should point to the > > beginning of the def (here 1:1, 4:1, and 7:1), but that positions of > > the various qualifiers (cdef, public, inline, api, ...) should be > > cached so that the error points to the offending qualifier. > > For better or for worse, Cython follows the same inane declarator > rules as C, so > > cdef int a, *b, c[5], (*d)(int) > > is valid. This colors how c function declarations are expressed in the > tree. Qualifiers don't really live in the tree and I'm not sure > plumbing the "qualifier node" positions around would be worth the > added complexity.
So should I go ahead and update the expected error messages in my branch? -- This email may be signed or encrypted with GPG (http://www.gnupg.org). The GPG signature (if present) will be attached as 'signature.asc'. For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
pgpb5IXeiawOW.pgp
Description: PGP signature
_______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
