Bug #9486

Multiple Kernel#local_variables entries with block local parameters

Added by Ryan Mulligan about 1 year ago. Updated 8 months ago.

[ruby-core:60501]
Status:Closed
Priority:Normal
Assignee:Nobuyoshi Nakada
ruby -v:ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-linux] Backport:1.9.3: REQUIRED, 2.0.0: DONE, 2.1: DONE

Description

Better formatting here: http://stackoverflow.com/questions/21423863/multiple-kernellocal-variables-entries-with-block-local-parameters/21427424?noredirect=1#21427424

I am using this version of Ruby on Arch Linux. I also tried the first code snippet in ruby 1.9, which had the same results.

ruby -v
ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-linux]
uname -a
Linux ryantm0j132 3.12.7-2-ARCH #1 SMP PREEMPT Sun Jan 12 13:09:09 CET 2014 x86_64 GNU/Linux

These three snippets below are separate programs.

When I use block local variables that shadow a variable the local_variables array contains 3 entries:

a = 1
puts local_variables.inspect #=> [:a]
proc { |;a|
puts local_variables.inspect #=> [:a,:a,:a]
}.call

If I don't shadow, anything it contains 1 entry:

puts local_variables.inspect #=> []
proc { |;b|
puts local_variables.inspect #=> [:b]
}.call

Another example of the block local variable not shadowing anything:

a = 1
puts local_variables.inspect #=> [:a]
proc { |;b|
puts local_variables.inspect #=> [:b,:a]
}.call

Is there some reason for these extra entries in the first case? Is it a bug in ruby?

Associated revisions

Revision 45847
Added by Nobuyoshi Nakada 10 months ago

missed ref. [Bug #9486]

Revision 45847
Added by Nobuyoshi Nakada 10 months ago

missed ref. [Bug #9486]

Revision 45850
Added by Nobuyoshi Nakada 10 months ago

vm_eval.c: exclude hidden variables

  • vm_eval.c (rb_f_local_variables): exclude variables hidden by shadowing. [Bug #9486]
  • vm.c (collect_local_variables_in_iseq): ditto.

Revision 45850
Added by Nobuyoshi Nakada 10 months ago

vm_eval.c: exclude hidden variables

  • vm_eval.c (rb_f_local_variables): exclude variables hidden by shadowing. [Bug #9486]
  • vm.c (collect_local_variables_in_iseq): ditto.

Revision 46596
Added by Tomoyuki Chikanaga 8 months ago

merge revision(s) r45845,r45846,r45847: [Backport #9486]

* parse.y (local_tbl_gen): remove local variables duplicated with
  arguments.

* parse.y (new_bv_gen): no duplicated names, if already added in
  shadowing_lvar().
   [Bug #9486]

Revision 46731
Added by Usaku NAKAMURA 8 months ago

merge revision(s) 45845,45847: [Backport #9786]

* parse.y (local_tbl_gen): remove local variables duplicated with
  arguments.
   [Bug #9486]

History

#1 Updated by Nobuyoshi Nakada about 1 year ago

  • Category set to core
  • Status changed from Open to Assigned
  • Assignee set to Nobuyoshi Nakada
  • Target version set to current: 2.2.0

It's a known bug, but I've forgotten to issue a ticket.
Thank you.

#2 Updated by Nobuyoshi Nakada about 1 year ago

  • Backport changed from 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN to 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: REQUIRED

#3 Updated by Nobuyoshi Nakada 10 months ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100

Applied in changeset r45847.


missed ref. [Bug #9486]

#4 Updated by Tomoyuki Chikanaga 9 months ago

Hello,

These changesets introduce incompatibilities.
I think r45845 and r45856 could be backported (these fix the result [:a, :a, :a] -> [:a, :a] in the ticket's description). r45850 seems like a spec change rather than a bugfix (hide shadowed variable of outer scope).
Any comments?

#5 Updated by Nobuyoshi Nakada 9 months ago

r45850 is not a subject to be backported.

#6 Updated by Tomoyuki Chikanaga 8 months ago

  • Backport changed from 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: REQUIRED to 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: DONE

r45845, r45846 and r45847 were backported into ruby_2_1 at r46596.

#7 Updated by Usaku NAKAMURA 8 months ago

  • Backport changed from 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: DONE to 1.9.3: REQUIRED, 2.0.0: DONE, 2.1: DONE

backported r45845 and r45847 into ruby_2_0_0 at r46731.

skipping r45846 because it's not the test for this change.
And, in fact, what is tested here is another problem that exists in the current state 2.0.0.
It is not known at this time how and when it has been fixed in trunk.

Also available in: Atom PDF