Well this is definitely a bug, and I think it's related to the parser.
Clues:
- The parser determines dvar versus lvar at parse time, using
ParserSupport's localNamesStack. As blocks are entered and exited, the
topmost LocalNamesElement is modified appropriately. When a bare
identifier is encountered, the parser uses that topmost
LocalNamesElement to determine whether to treat it as a dvar, lvar, or
vcall.
- When the parser is invoked for an eval, the ParserSupport it uses
gets reset to defaults. Once the parser initializes, it then calls
ParserSupport.initTopLocalVariables, which gets a set of local
variable names from RubyParserConfiguration object passed into
parse(). RubyParserConfiguration uses the current scope to retrieve
that list of local variable names, which does not include dvars
created during block execution. This process does not initialize
"inside block" status, however, and so all variables parsed at runtime
are considered to be local variables (unless of course the code to be
parsed has blocks, which set the state accordingly).
I believe that by extending ParserSupport and RubyParserConfiguration
to be block-aware, essentially by checking if we are inside a block
and setting state as appropriate, we can resolve this bug. It would
seem to me that this is a fairly egregious fault in JRuby and fixing
it would be a major correction.
I'll see what I can whip up before v-day fesitivities.
On 2/14/06, Charles O Nutter <[EMAIL PROTECTED]> wrote:
> There seems to be an issue either with how block-local variables are
> stored or how eval'ed code looks them up. The following fails because
> x is treated as a local variable, rather than a dyn variable, and so
> the interpreter tries to find it in the block's containing scope,
> rather than in its dyn var list:
>
> def foo
> yield
> end
>
> foo { x = "bar"; eval("puts x") }
>
> Obviously this should work. Is it an issue that the parser doesn't
> know how to treat the reference to x, and so tries to look it up as a
> local var rather than a dvar?
>
> This is the current stopper for Rails' generate script.
>
> --
> Charles Oliver Nutter @ headius.blogspot.com
> JRuby Developer @ jruby.sourceforge.net
> Application Architect @ www.ventera.com
>
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Jruby-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jruby-devel
