Re: semantic error: cannot expand unknown type

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

> > - The parser does not recognize keywords as such.  [...]
> [...]
> We've got several cases of a single token being used for multiple uses:

Yikes.  Thanks for giving it a start.

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

A more elegant approach for these may be to explicitly accept either
tok_identifier or tok_keyword elements in parse_probe_point().  I
would not hard-code "return" and "function" in this way.

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

We should outlaw the latter two (and rename or remove the current
string() function in conversions.stp).

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

These will all go away if the parse functions related to
expressions/symbols refuse to accept tok_keyword.  That "global
global" test case would have to be changed.  The parser should end up
with no strange hacks.

(e.g., expect_unknown() should not need to be changed at all; "string"
and "global" indeed shouldn't show up in parse_statement() or
parse_functiondecl() or so on.)


> My suggestion would be to "reserve" keywords, so that using keywords as
> function names, parameter names, or variable names isn't allowed.  [...]

That is in effect what would happen if the new tok_keyword token class
is not permitted in most terminals.

> [...] 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.

What is the parse tree (-p1) that results from your test case, after
the parser changes?

- FChE