[ruby-core:77684] [Ruby trunk Bug#12855] Inconsistent keys identity in compare_by_identity Hash when using literals

[ruby-core:77684] [Ruby trunk Bug#12855] Inconsistent keys identity in compare_by_identity Hash when using literals

[eregontp]

Issue #12855 has been reported by Benoit Daloze.

----------------------------------------
Bug #12855: Inconsistent keys identity in compare_by_identity Hash when using literals
https://bugs.ruby-lang.org/issues/12855

* Author: Benoit Daloze
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
This seems a regression since 2.2.
I would guess it's due to some optimization for having a string literal between []=.
That optimization should not trigger for compare_by_identity hashes, so both cases below are consistent.

~~~ruby
h = {}.compare_by_identity
h['pear'] = 1
h['pear'] = 2

p h.size # => 1
p h


h = {}.compare_by_identity
k1 = 'pear'
h[k1] = 1
k2 = 'pear'
h[k2] = 2

p h.size # => 2
p h
~~~



-- 
https://bugs.ruby-lang.org/

[ruby-core:77685] [Ruby trunk Bug#12855] Inconsistent keys identity in compare_by_identity Hash when using literals

[merch-redmine]

Issue #12855 has been updated by Jeremy Evans.


While this was a behavior change between 2.1 and 2.2, I'm not sure I would consider it a regression.  It seems unlikely anyone who uses compare_by_identity hashes would also be using string literals and want string literals keys to have different values.

If we do decide to revert to 2.1 behavior for string literals, at the very least we should make sure that on ruby 2.1+:

~~~ ruby
h = {}.compare_by_identity
h['pear'.freeze] = 1
h['pear'.freeze] = 2

p h.size # => 1
# because 'pear'.freeze.equal?('pear'.freeze)
~~~

and on ruby 2.3+:

~~~ ruby
# frozen-string-literal: true
# or when using --enable-frozen-string-literal
h = {}.compare_by_identity
h['pear'] = 1
h['pear'] = 2

p h.size # => 1
# because 'pear'.equal?('pear')
~~~

----------------------------------------
Bug #12855: Inconsistent keys identity in compare_by_identity Hash when using literals
https://bugs.ruby-lang.org/issues/12855#change-60968

* Author: Benoit Daloze
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
This seems a regression since 2.2.
I would guess it's due to some optimization for having a string literal between []=.
That optimization should not trigger for compare_by_identity hashes, so both cases below are consistent.

~~~ruby
h = {}.compare_by_identity
h['pear'] = 1
h['pear'] = 2

p h.size # => 1
p h


h = {}.compare_by_identity
k1 = 'pear'
h[k1] = 1
k2 = 'pear'
h[k2] = 2

p h.size # => 2
p h
~~~



-- 
https://bugs.ruby-lang.org/

[ruby-core:77688] [Ruby trunk Bug#12855] Inconsistent keys identity in compare_by_identity Hash when using literals

[eregontp]

Issue #12855 has been updated by Benoit Daloze.


Jeremy Evans wrote:
> While this was a behavior change between 2.1 and 2.2, I'm not sure I would consider it a regression.
> It seems unlikely anyone who uses compare_by_identity hashes would also be using string literals and want string literals keys to have different values.

The main reason I consider it a bug is that it contradicts the very basic intuition that replacing a literal with an expression producing it has identical behavior.
For example, `"z = #{3*4}"` vs `r = 12; "z = #{r}"`.
While of course a much smaller area of exposition,
I think there is no reason to introduce this change (and I'm fairly confident it was not intended).

----------------------------------------
Bug #12855: Inconsistent keys identity in compare_by_identity Hash when using literals
https://bugs.ruby-lang.org/issues/12855#change-60970

* Author: Benoit Daloze
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
This seems a regression since 2.2.
I would guess it's due to some optimization for having a string literal between []=.
That optimization should not trigger for compare_by_identity hashes, so both cases below are consistent.

~~~ruby
h = {}.compare_by_identity
h['pear'] = 1
h['pear'] = 2

p h.size # => 1
p h


h = {}.compare_by_identity
k1 = 'pear'
h[k1] = 1
k2 = 'pear'
h[k2] = 2

p h.size # => 2
p h
~~~



-- 
https://bugs.ruby-lang.org/

[ruby-core:78766] [Ruby trunk Bug#12855][Assigned] Inconsistent keys identity in compare_by_identity Hash when using literals

[shyouhei]

Issue #12855 has been updated by Shyouhei Urabe.

Status changed from Open to Assigned
Assignee set to Eric Wong

----------------------------------------
Bug #12855: Inconsistent keys identity in compare_by_identity Hash when using literals
https://bugs.ruby-lang.org/issues/12855#change-62167

* Author: Benoit Daloze
* Status: Assigned
* Priority: Normal
* Assignee: Eric Wong
* Target version: 
* ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
This seems a regression since 2.2.
I would guess it's due to some optimization for having a string literal between []=.
That optimization should not trigger for compare_by_identity hashes, so both cases below are consistent.

~~~ruby
h = {}.compare_by_identity
h['pear'] = 1
h['pear'] = 2

p h.size # => 1
p h


h = {}.compare_by_identity
k1 = 'pear'
h[k1] = 1
k2 = 'pear'
h[k2] = 2

p h.size # => 2
p h
~~~



-- 
https://bugs.ruby-lang.org/

[ruby-core:78783] [Ruby trunk Bug#12855] Inconsistent keys identity in compare_by_identity Hash when using literals

[shyouhei]

Issue #12855 has been updated by Shyouhei Urabe.

Assignee changed from Eric Wong to Aman Gupta

We looked at this issue at today's developer meeting.  It seems over-optimization as Benoit originally guessed.  Let me assign this to Aman.

----------------------------------------
Bug #12855: Inconsistent keys identity in compare_by_identity Hash when using literals
https://bugs.ruby-lang.org/issues/12855#change-62190

* Author: Benoit Daloze
* Status: Assigned
* Priority: Normal
* Assignee: Aman Gupta
* Target version: 
* ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
This seems a regression since 2.2.
I would guess it's due to some optimization for having a string literal between []=.
That optimization should not trigger for compare_by_identity hashes, so both cases below are consistent.

~~~ruby
h = {}.compare_by_identity
h['pear'] = 1
h['pear'] = 2

p h.size # => 1
p h


h = {}.compare_by_identity
k1 = 'pear'
h[k1] = 1
k2 = 'pear'
h[k2] = 2

p h.size # => 2
p h
~~~



-- 
https://bugs.ruby-lang.org/

[ruby-core:78797] Re: [Ruby trunk Bug#12855] Inconsistent keys identity in compare_by_identity Hash when using literals

[Eric Wong]

Unintentional, yes, but maybe moot since frozen_string_literal
is going to be default in the future (maybe that case changed?)

Anyways, I hate this patch because it makes insns.def bigger,
and insns.def is already too big IMHO:

   https://80x24.org/spew/20161222004752.4086-1-e@80x24.org/raw

Somebody else can commit; I hate it too much.

[ruby-core:78805] [Ruby trunk Bug#12855] Inconsistent keys identity in compare_by_identity Hash when using literals

[eregontp]

Issue #12855 has been updated by Benoit Daloze.


Eric Wong wrote:
> Unintentional, yes, but maybe moot since frozen_string_literal
>  is going to be default in the future (maybe that case changed?)
>  
>  Anyways, I hate this patch because it makes insns.def bigger,
>  and insns.def is already too big IMHO:
>  
>  https://80x24.org/spew/20161222004752.4086-1-e@80x24.org/raw
>  
>  Somebody else can commit; I hate it too much.

Thank you for the patch!
I would like to commit it then, unless there is an objection.

IMHO optimizations have to be correct, even in edge cases.
Such instructions are already a trade-off of duplication and complexity for speed improvement,
so this small change in size does not matter much to me.
Optimizations need to be totally transparent to the user to be called as such.

----------------------------------------
Bug #12855: Inconsistent keys identity in compare_by_identity Hash when using literals
https://bugs.ruby-lang.org/issues/12855#change-62212

* Author: Benoit Daloze
* Status: Assigned
* Priority: Normal
* Assignee: Aman Gupta
* Target version: 
* ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
This seems a regression since 2.2.
I would guess it's due to some optimization for having a string literal between []=.
That optimization should not trigger for compare_by_identity hashes, so both cases below are consistent.

~~~ruby
h = {}.compare_by_identity
h['pear'] = 1
h['pear'] = 2

p h.size # => 1
p h


h = {}.compare_by_identity
k1 = 'pear'
h[k1] = 1
k2 = 'pear'
h[k2] = 2

p h.size # => 2
p h
~~~



-- 
https://bugs.ruby-lang.org/

[ruby-core:80021] [Ruby trunk Bug#12855] Inconsistent keys identity in compare_by_identity Hash when using literals

[naruse]

Issue #12855 has been updated by Yui NARUSE.

Backport changed from 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN to 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: DONE

ruby_2_4 r57848 merged revision(s) 57278,57279.

----------------------------------------
Bug #12855: Inconsistent keys identity in compare_by_identity Hash when using literals
https://bugs.ruby-lang.org/issues/12855#change-63442

* Author: Benoit Daloze
* Status: Closed
* Priority: Normal
* Assignee: Aman Gupta
* Target version: 
* ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: DONE
----------------------------------------
This seems a regression since 2.2.
I would guess it's due to some optimization for having a string literal between []=.
That optimization should not trigger for compare_by_identity hashes, so both cases below are consistent.

~~~ruby
h = {}.compare_by_identity
h['pear'] = 1
h['pear'] = 2

p h.size # => 1
p h


h = {}.compare_by_identity
k1 = 'pear'
h[k1] = 1
k2 = 'pear'
h[k2] = 2

p h.size # => 2
p h
~~~



-- 
https://bugs.ruby-lang.org/

[ruby-core:80087] [Ruby trunk Bug#12855] Inconsistent keys identity in compare_by_identity Hash when using literals

[nagachika00]

Issue #12855 has been updated by Tomoyuki Chikanaga.

Backport changed from 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: DONE to 2.1: UNKNOWN, 2.2: REQUIRED, 2.3: REQUIRED, 2.4: DONE

----------------------------------------
Bug #12855: Inconsistent keys identity in compare_by_identity Hash when using literals
https://bugs.ruby-lang.org/issues/12855#change-63513

* Author: Benoit Daloze
* Status: Closed
* Priority: Normal
* Assignee: Aman Gupta
* Target version: 
* ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]
* Backport: 2.1: UNKNOWN, 2.2: REQUIRED, 2.3: REQUIRED, 2.4: DONE
----------------------------------------
This seems a regression since 2.2.
I would guess it's due to some optimization for having a string literal between []=.
That optimization should not trigger for compare_by_identity hashes, so both cases below are consistent.

~~~ruby
h = {}.compare_by_identity
h['pear'] = 1
h['pear'] = 2

p h.size # => 1
p h


h = {}.compare_by_identity
k1 = 'pear'
h[k1] = 1
k2 = 'pear'
h[k2] = 2

p h.size # => 2
p h
~~~



-- 
https://bugs.ruby-lang.org/

[ruby-core:80331] [Ruby trunk Bug#12855] Inconsistent keys identity in compare_by_identity Hash when using literals

[usa]

Issue #12855 has been updated by usa (Usaku NAKAMURA).

Backport changed from 2.1: UNKNOWN, 2.2: REQUIRED, 2.3: REQUIRED, 2.4: DONE to 2.1: UNKNOWN, 2.2: DONE, 2.3: REQUIRED, 2.4: DONE

ruby_2_2 r58099 merged revision(s) 57278,57279.

----------------------------------------
Bug #12855: Inconsistent keys identity in compare_by_identity Hash when using literals
https://bugs.ruby-lang.org/issues/12855#change-63808

* Author: Eregon (Benoit Daloze)
* Status: Closed
* Priority: Normal
* Assignee: tmm1 (Aman Gupta)
* Target version: 
* ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]
* Backport: 2.1: UNKNOWN, 2.2: DONE, 2.3: REQUIRED, 2.4: DONE
----------------------------------------
This seems a regression since 2.2.
I would guess it's due to some optimization for having a string literal between []=.
That optimization should not trigger for compare_by_identity hashes, so both cases below are consistent.

~~~ruby
h = {}.compare_by_identity
h['pear'] = 1
h['pear'] = 2

p h.size # => 1
p h


h = {}.compare_by_identity
k1 = 'pear'
h[k1] = 1
k2 = 'pear'
h[k2] = 2

p h.size # => 2
p h
~~~



-- 
https://bugs.ruby-lang.org/

[ruby-core:80392] [Ruby trunk Bug#12855] Inconsistent keys identity in compare_by_identity Hash when using literals

[nagachika00]

Issue #12855 has been updated by nagachika (Tomoyuki Chikanaga).

Backport changed from 2.1: UNKNOWN, 2.2: DONE, 2.3: REQUIRED, 2.4: DONE to 2.1: UNKNOWN, 2.2: DONE, 2.3: DONE, 2.4: DONE

ruby_2_3 r58166 merged revision(s) 57278,57279.

----------------------------------------
Bug #12855: Inconsistent keys identity in compare_by_identity Hash when using literals
https://bugs.ruby-lang.org/issues/12855#change-63881

* Author: Eregon (Benoit Daloze)
* Status: Closed
* Priority: Normal
* Assignee: tmm1 (Aman Gupta)
* Target version: 
* ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]
* Backport: 2.1: UNKNOWN, 2.2: DONE, 2.3: DONE, 2.4: DONE
----------------------------------------
This seems a regression since 2.2.
I would guess it's due to some optimization for having a string literal between []=.
That optimization should not trigger for compare_by_identity hashes, so both cases below are consistent.

~~~ruby
h = {}.compare_by_identity
h['pear'] = 1
h['pear'] = 2

p h.size # => 1
p h


h = {}.compare_by_identity
k1 = 'pear'
h[k1] = 1
k2 = 'pear'
h[k2] = 2

p h.size # => 2
p h
~~~



-- 
https://bugs.ruby-lang.org/