Неправильный вывод метода Hash # keys

Question

При определенных условиях Hash#keys работает некорректно в Ruby до версии 2.4

Демонстрационный код:

h = { a: 1, b: 2, c: 3 }
h.each do |k, v|
    h.delete(:a)
    p h
    p h.keys
    break
end

Выход Ruby 2.3.8:

{:b=>2, :c=>3}
[:b]

Вывод Ruby 2.5.1:

{:b=>2, :c=>3}
[:b, :c]

Я согласен, что неправильно изменять хеш при итерации.Но я не видел связи между модификацией хэша и методом рабочих ключей.

Почему это происходит?

Answer 1

Интересный вопрос.Это еще не ответ, но он слишком длинный для комментария и может помочь другим ответить на вопрос.

Какие рубины затронуты?

Я создал GitHub хранилище с очень простой спецификацией:

describe Hash do
  it "should always know which keys are left" do
    h = { a: 1, b: 2, c: 3 }
    h.each do |k, v|
      h.delete :a
      expect(h.keys).to eq [:b, :c]
    end
  end
end

Благодаря Travis легко увидеть, в каких версиях Ruby есть эта ошибка:

• Ruby 2.1
• Ruby 2.2
• Ruby 2.3

Когда появилась ошибка?

• Ошибкаотсутствует в ruby-2.1.0-preview2
• Ошибка была в ruby-2.1.0-rc1

Когдабыла ли исправлена ​​ошибка?

• https://github.com/ruby/ruby/tree/v2_4_0_preview2 был последним тегом с этой ошибкой.
• https://github.com/ruby/ruby/tree/v2_4_0_preview3 - первый тег без этой ошибки.

Я просто потратил час, используя git bisect и make install, чтобы обнаружить, что ошибка была исправлена ​​в этом коммите (75775157) .

Представляем улучшение таблицы от Владимира Макарова.

[Feature # 12142] Смотрите головуСтр. c для улучшения деталей.

Вы можете увидеть всю историю кода здесь: https://github.com/vnmakarov/ruby/tree/hash_tables_with_open_addressing

Это улучшение обсуждается на https://bugs.ruby -lang.org / questions/ 12142 со многими людьми, особенно с Юрой Соколовым.

• st.c: улучшение st_table.

• include / ruby ​​/ st.h: то же самое.

• internal.h, numeric.c, hash.c (rb_dbl_long_hash): извлечь функцию.

• ext /-test- / st / foreach / foreach.c: поймать это изменение.

git-svn-id: svn + ssh: //ci.ruby-lang.org/ruby/ trunk @ 56650 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Это было подтверждено @Vovan, который обнаружил этот коммит за 1 минуту до того, как я это сделал.