semantic error: cannot expand unknown type

[David Smith]

On Wed, 2006-05-10 at 21:04 -0400, Frank Ch. Eigler wrote:
> Hi, David -

... stuff deleted ...

> > 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:

> - 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

I've been trying to wrap my head around the parser so I could give this
a try.  I added the "tok_keyword" tok_type enumeration and added code to
lexer::scan() to recognize keywords.

We've got several cases of a single token being used for multiple uses:

The token "function" - it has 2 different uses:

- as a keyword, as in 'function foo()'
- as an identifier, as in 'probe kernel.function("sys_read")'

The token "return" - it has 2 different uses:

- as a keyword, as in "function foo() { return; }"
- as an identifier, as in "probe kernel.function("sys_read").return'

The above two seem reasonable and I've worked around them (not very
elegantly).


Then there are the odd cases, like:

The token "string" - it has (at least) 3 different uses:

- as a keyword, as in "function foo(a:string)"
- as an identifier as in the name of a function, like "function
string:string(num:long)" (as is done in conversions.stp)
- as an identifier as in the name of a variable, like 'string = "abc"'

Note that there are other keywords that could be used similarly.  The
keyword "long" could be used as a function name or variable name.  The
keywords "if", "while", "foreach", etc. can be used as function names
(of course they will never get called, but still).  The keyword "global"
can be used as a variable name (and is in the testsuite that way).  The
keyword "probe" could be used as a variable name.

Also note that the parser currently lets you do silly things like:

    function foo(while:long)
    {
        printf("foo: %d\n", while);
    }

which will fail during compilation, but the parser could catch it.

My suggestion would be to "reserve" keywords, so that using keywords as
function names, parameter names, or variable names isn't allowed.  Note
that this would require changing conversions.stp (and any script that
calls the "string" function).

So, do we want to "reserve" keywords?


Here is my current code in patch form with enough workarounds for the
issues above to make it through the testsuite with the same results as
without the patches.  If we don't reserve keywords, more workarounds
will need to be added.

Also note that we could speed things up a bit by adding a new
enumeration to "struct token" of something like 'keyword_type', so we
only have to do the string compares once for tokens (but there wasn't a
point to doing that until the main approach is accepted).

Finally note that this doesn't actually solve my original problem of
using "return" instead of "next" in a probe but is a step in that
direction.

-- 
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: 11871 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20060512/08b36d1b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parse.h-patch
Type: text/x-patch
Size: 505 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20060512/08b36d1b/attachment-0001.bin>