Re: semantic error: cannot expand unknown type

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

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.


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


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