semantic error: cannot expand unknown type

[David Smith]

Frank Ch. Eigler wrote:

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

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

Perhaps we could take a hybrid approach.  Instead of tok_types being 
exclusive, what if they were a set of flags instead.  Then, the "return" 
and "function" tokens could be both identifiers and keywords at the same 
time.

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

>>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.
>  
>
Glad we agree here too.  I was just trying to point out some of the 
existing oddities.

I've removed all the hacks (except for the one in parse_probe_point() 
that we were discussing above).

>(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.)
>  
>
When I removed all the hacks, I didn't need to change "expect_unknown()" 
at all.  I've attached a new patch.

>  
>
>>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
>  
>
I've attached the whole thing, but the relevant part is here:

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.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: parse.cxx-patch
URL: <http://sourceware.org/pipermail/systemtap/attachments/20060512/51f61775/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rwtop_fail.parse
URL: <http://sourceware.org/pipermail/systemtap/attachments/20060512/51f61775/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rwtop_fail.stp
URL: <http://sourceware.org/pipermail/systemtap/attachments/20060512/51f61775/attachment-0002.ksh>