Trying to set variable inside struct crashes parser

[hoytak@…]

Hello,

As of r1117, trying to set a variable inside a struct crashes the parser. For example, running cython on the following code:

cdef struct MyStruct?:

int a = 10

causes this:

user@ubuntu804desktop:~/code/rf$ cython testfile.pyx Traceback (most recent call last):

File "/home/user/sysroot/bin/cython", line 8, in <module>

main(command_line = 1)

File "/home/user/sysroot/lib/python2.5/site-packages/Cython/Compiler/Main.py", line 698, in main

result = compile(sources, options)

File "/home/user/sysroot/lib/python2.5/site-packages/Cython/Compiler/Main.py", line 675, in compile

return compile_multiple(source, options)

File "/home/user/sysroot/lib/python2.5/site-packages/Cython/Compiler/Main.py", line 645, in compile_multiple

result = run_pipeline(source, options)

File "/home/user/sysroot/lib/python2.5/site-packages/Cython/Compiler/Main.py", line 507, in run_pipeline

err, enddata = context.run_pipeline(pipeline, source)

File "/home/user/sysroot/lib/python2.5/site-packages/Cython/Compiler/Main.py", line 169, in run_pipeline

data = phase(data)

File "/home/user/sysroot/lib/python2.5/site-packages/Cython/Compiler/ParseTreeTransforms.py", line 476, in call

return super(AnalyseDeclarationsTransform?, self).call(root)

File "/home/user/sysroot/lib/python2.5/site-packages/Cython/Compiler/Visitor.py", line 156, in call

return self.visit(root)

File "/home/user/sysroot/lib/python2.5/site-packages/Cython/Compiler/Visitor.py", line 37, in visit

return m(obj)

File "/home/user/sysroot/lib/python2.5/site-packages/Cython/Compiler/ParseTreeTransforms.py", line 479, in visit_ModuleNode

node.analyse_declarations(self.env_stack[-1])

File "/home/user/sysroot/lib/python2.5/site-packages/Cython/Compiler/ModuleNode.py", line 55, in analyse_declarations

self.body.analyse_declarations(env)

File "/home/user/sysroot/lib/python2.5/site-packages/Cython/Compiler/Nodes.py", line 267, in analyse_declarations

stat.analyse_declarations(env)

File "/home/user/sysroot/lib/python2.5/site-packages/Cython/Compiler/Nodes.py", line 710, in analyse_declarations

attr.analyse_declarations(env, scope)

TypeError?: analyse_declarations() takes exactly 2 arguments (3 given)

Thanks!

[hoytak@…]

It seems an easy fix is to simply eliminate the scope argument:

diff -r 432133046744 Cython/Compiler/Nodes.py --- a/Cython/Compiler/Nodes.py Wed Aug 27 09:12:51 2008 +0200 +++ b/Cython/Compiler/Nodes.py Wed Aug 27 11:01:55 2008 -0400 @@ -707,7 +707,7 @@ class CStructOrUnionDefNode(StatNode?):

if self.in_pxd and not env.in_cinclude:

self.entry.defined_in_pxd = 1

for attr in self.attributes:

- attr.analyse_declarations(env, scope) + attr.analyse_declarations(env)

def analyse_expressions(self, env):

pass

However, I think an expert should look at this. When this fix is run on the above sample, it gives:

Error converting Pyrex file to C:

---

... cdef struct MyStruct?:

---

/home/user/code/rf/testcase.pyx:1:5: Empty struct or union definition not allowed outside a 'cdef extern from' block

which isn't the most intuitive error message.

--Hoyt

[dagss]

I don't have proper computer access (Windows only) at the moment so all you get is this input:

I don't think removing the scope argument is the right thing to do, that very likely will break other stuff. The thing is that this isn't legal code and likely just triggers an unforeseen execution path.

I think the fix for this is very easy (but as I said I don't have proper computer access): In ParseTreeTransforms?.py, in the PostParse? class. There one already disallows this for cdef classes (when visiting a CVarDefNode) and it should be very straightforward to extend this to structs. Then one can pick whatever error message one likes :-)

Thanks for the bug report!

[dagss]

Patch for raising compiler error in this situation

[dagss]

I added a patch against the stable repo for disallowing this syntax, however I didn't commit it yet as I am unsure about whether this syntax earlier had a purpose?

[dagss]

Hoyt wrote:
> Dag wrote:
> > To be clear, you say "as of r1117", does that mean that this used to
> > work prior to r1117?
> >
> > I.e. did the feature use to work and then got broken, or was this never
> > allowed?

No, it was my first time trying it, so I have no evidence it ever worked.

So, pushing this and closing.