This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: semantic error: cannot expand unknown type
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: David Smith <dsmith at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Wed, 10 May 2006 21:04:33 -0400
- Subject: Re: semantic error: cannot expand unknown type
- References: <1147293145.9884.26.camel@dhcp-2.hsv.redhat.com>
Hi, David -
> [...] Yesterday we had this conversation:
> 1. (16:05:58) dsmith: I'm getting "semantic error: cannot expand
> unknown type" with no indication of which variable it is
> complaining about. Got any tips on how to track it down?
> (16:06:49) fche: not pointing out a source coordinate is a bug. find the
> message in the translator source, and make it spit out the object's
> token, like the other error messages do.
> (16:08:06) dsmith: k, will do
>
> So, I looked into it. That error message came from
> c_unparser::c_typename(). [...]
OK.
> rwtop_fail.stp - Stap source file that triggers the error. The problem
> is that I used "if (xyz) return" in a probe that should have been "if
> (xyz) next". The parser grabbed the next token and tried to figure out
> what it was returning.
>
> 1) Is this approach correct? Could it have been done with less impact
> or in a better manner?
Before that "declare" operation, the translator code could do a quick
local unknown-type check before calling down to c_unparser, and punt.
The c_unparser::c_typename code might assert() type validity outright.
> 2) Should this be scrapped and the parser somehow upgraded to notice
> I was using a "return" instead of "next"?
There are a couple of different shortcomings there:
- In "if (cond) next", "next" should have been optimized out (replaced
with a null statement), since it's a side-effect-free expression
statement. It's related to bug #2600.
- The parser does not recognize keywords as such. Keywords are just
tok_identifier instances with magic names. It would be nice if a
list of keywords was given to the scanner, and a new tok_keyword tag
was used to represent them. Then this "if (cond) next" would have
been a parse error. This is probably a worthwhile, somewhat
mechanical change throughout parser.h/cxx. At least our test suite
should be enough for the "ok" case. Want to give it a try?
- FChE