semantic error: cannot expand unknown type
David Smith
dsmith@redhat.com
Mon May 15 17:20:00 GMT 2006
On Fri, 2006-05-12 at 18:43 -0400, Frank Ch. Eigler wrote:
> Hi -
>
> dsmith wrote:
>
> > [...] Yeah, it is a bit ugly. However, if we don't explicitly only
> > take "return" and "function" here, then the user is free to write
> > 'probe kernel.while("sys_read").if'.
>
> I'd be OK with that. We can keep a separate namespace for probe
> points.
OK. I've allowed all keywords there.
> > [...]
> > >We should outlaw the latter two (and rename or remove the current
> > >string() function in conversions.stp).
> > >
> > Glad we agree. What do we want to rename the string() function to?
> > ltoa()? long2str()? long_to_string()? Or something else? I'd probably
> > pick "long_to_string()".
>
> Or just remove it altogether: sprint(<numeric-expression>) is equivalent.
True. What about the hexstring() function in conversions.stp (which
also calls sprintf)?
>
> > [...]
> > if (!(ok)) return (value) = (retval())
> > When the parser sees the return, it isn't smart enough to realize that a
> > return keyword isn't valid in a probe point, only in a function.
>
> Yes, and similarly with "next". Detecting the wrong "escape"
> statement is left to translation time. One could fix the parser in a
> couple of little ways:
> - parametrize the statement parsers, passing along a "in_function_p" flag
> that originates from from parse_functiondecl() and parse_probe()
> - or pass the equivalent flag within a parser class member variable
> - or fork the parse_stmt_block and parse_statement
>
> The first and second of these seem okay, only slightly noxious.
> The third has a theorist's respect and an engineer's disdain. :-)
>
> - FChE
I took the second route. See the attached patch.
--
David Smith
dsmith@redhat.com
Red Hat, Inc.
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parse.cxx-patch
Type: text/x-patch
Size: 12021 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20060515/65d68f66/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parse.h-patch
Type: text/x-patch
Size: 803 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20060515/65d68f66/attachment-0001.bin>
More information about the Systemtap
mailing list