[Issue 16973] `hashOf` has error-prone signature as `(T, seed)` may be confused with `(ptr, length)`

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16973

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@gmail.com

--- Comment #5 from Steven Schveighoffer  ---
I would recommend this be closed as WONTFIX.

If you don't follow the specification of the function, I don't see how you
expect to get correct results.

--

[Issue 16973] `hashOf` has error-prone signature as `(T, seed)` may be confused with `(ptr, length)`

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16973

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P2

--

[Issue 19239] Fix unsafe casting away of const in hashOf(const Object)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19239

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P3

--

[Issue 21947] RedBlackTree and hashOf do not play well together

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21947

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P3

--

[Issue 21947] RedBlackTree and hashOf do not play well together

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21947

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@gmail.com

--- Comment #1 from Steven Schveighoffer  ---
This recently came up again:
https://forum.dlang.org/post/kcrkxqsoeziyxouhb...@forum.dlang.org

It's because the machinery to infer @safe and nothrow is not done for class
methods, even on templated classes.

What needs to happen is a 2-layer method for `toHash`, where one is inferred,
and the other one must copy the attributes.

I'm not sure why the hard-coded attributes were added, but they seem to have
been added when `toHash` was added.

--

[Issue 22136] [REG 2.097.1] hashOf failed to compile because of different inheritance order

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22136

--- Comment #6 from Dlang Bot  ---
dlang/dmd pull request #13785 "merge stable" was merged into master:

- da491b8ada5f557a222c369f7f1bb481ca10880e by Nathan Sashihara:
  Revert "Fix Issue 22136 - [REG 2.097.1] hashOf failed to compile because of
different inheritance order (#13404)" (#13745)

  This reverts commit 646ec178ffa13cf596026dae4217fdad27ad777c.

https://github.com/dlang/dmd/pull/13785

--

[Issue 22136] [REG 2.097.1] hashOf failed to compile because of different inheritance order

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22136

--- Comment #5 from Dlang Bot  ---
dlang/dmd pull request #13745 "Revert "Fix Issue 22136 - [REG 2.097.1] hashOf
failed to compile because of d…"" was merged into stable:

- 646fe4e97e1dae3e083ae461931f123f036bd4cf by Nathan Sashihara:
  Revert "Fix Issue 22136 - [REG 2.097.1] hashOf failed to compile because of
different inheritance order (#13404)"

  This reverts commit 646ec178ffa13cf596026dae4217fdad27ad777c.

https://github.com/dlang/dmd/pull/13745

--

[Issue 22136] [REG 2.097.1] hashOf failed to compile because of different inheritance order

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22136

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Dlang Bot  ---
dlang/dmd pull request #13404 "Fix Issue 22136 - [REG 2.097.1] hashOf failed to
compile because of d…" was merged into stable:

- 289394fab4695d3f601767ea004f9c1737880395 by Eduard Staniloiu:
  Fix Issue 22136 - [REG 2.097.1] hashOf failed to compile because of different
inheritance order

https://github.com/dlang/dmd/pull/13404

--

[Issue 22136] [REG 2.097.1] hashOf failed to compile because of different inheritance order

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22136

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #3 from Dlang Bot  ---
@edi33416 created dlang/dmd pull request #13404 "Fix Issue 22136 - [REG
2.097.1] hashOf failed to compile because of d…" fixing this issue:

- Fix Issue 22136 - [REG 2.097.1] hashOf failed to compile because of different
inheritance order

https://github.com/dlang/dmd/pull/13404

--

[Issue 22136] [REG 2.097.1] hashOf failed to compile because of different inheritance order

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22136

--- Comment #2 from Eduard Staniloiu  ---
I did some digging on this, and the bug actually stems from the following issue

```
interface IObject
{
   size_t toHash() @trusted nothrow;
}

interface Dummy {}
interface Bug(E) : Dummy, IObject {}   
   
   
   
   interface OK(E) : IObject, Dummy {}

static assert(is(immutable OK!string* : immutable IObject*))); // OK
static assert(is(immutable Bug!string* : immutable IObject*))); // fails
```

It appears that the order affects the is expression and
the `is(immutable T* : immutable U*)` check is done inside the `hashOf`
function.

I'm currently investigating this in dmd.

--

[Issue 22136] [REG 2.097.1] hashOf failed to compile because of different inheritance order

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22136

Eduard Staniloiu  changed:

   What|Removed |Added

 CC||edi33...@gmail.com
   Assignee|nob...@puremagic.com|edi33...@gmail.com

--

[Issue 22136] [REG 2.097.1] hashOf failed to compile because of different inheritance order

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22136

Tejas_Garhewal  changed:

   What|Removed |Added

 CC||scientic...@gmail.com

--- Comment #1 from Tejas_Garhewal  ---
Seems to be a regression.

Works fine on dmd 2.097.0
(https://run.dlang.io/gist/cb1ed3bd5db4cf5b99e26454116b969a?args=-h)

Works fine on ldc2 1.25.0 (based on 2.095.1)

--

[Issue 22136] [REG 2.097.1] hashOf failed to compile because of different inheritance order

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22136

Paul Backus  changed:

   What|Removed |Added

 CC||snarwin+bugzi...@gmail.com
Summary|hashOf failed to compile|[REG 2.097.1] hashOf failed
   |because of different|to compile because of
   |inheritance order in DMD|different inheritance order
   |2.097.1 |
   Severity|critical|regression

--

[Issue 21005] Speed up hashOf for associative arrays

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21005

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Dlang Bot  ---
dlang/druntime pull request #3147 "Speed up hashOf for associative arrays" was
merged into master:

- d1142b8005d26741b596f3d7d3ed0acdb902a7a1 by Nathan Sashihara:
  Fix Issue 21005 - Speed up hashOf for associative arrays

https://github.com/dlang/druntime/pull/3147

--

[Issue 22076] hashOf(S) can segfault if S.toHash is forwarded via 'alias this' to a receiver which may be null

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22076

--- Comment #3 from Dlang Bot  ---
dlang/druntime pull request #3515 "merge stable" was merged into master:

- ed76256b7dd63748ba135467e9d8be5722b579cc by Nathan Sashihara:
  Fix 22076 - hashOf(S) can segfault if S.toHash is forwarded via 'alias this'
to a receiver which may be null

- 186e58071e35ac1866f371b44b50cf560ef06f9b by Nathan Sashihara:
  Fix 22076 - hashOf(S) can segfault if S.toHash is forwarded via 'alias this'
to a receiver which may be null

https://github.com/dlang/druntime/pull/3515

--

[Issue 22024] hashOf does not work on enum types whose base type is a SIMD vector

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22024

--- Comment #3 from Dlang Bot  ---
dlang/druntime pull request #3515 "merge stable" was merged into master:

- 4aa8c47d8fee3f2389dcb4408412a307d15b0393 by Nathan Sashihara:
  Fix Issue 22024 - hashOf does not work on enum types whose base type is a
SIMD vector

  Also incidentally do not pass vector by ref to toHash

- 324dca6924266be7415c50744d8a4dc74d43d407 by Nathan Sashihara:
  Fix Issue 22024 - hashOf does not work on enum types whose base type is a
SIMD vector

  Also incidentally do not pass vector by ref to toHash

https://github.com/dlang/druntime/pull/3515

--

[Issue 22136] New: hashOf failed to compile because of different inheritance order in DMD 2.097.1

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22136

  Issue ID: 22136
   Summary: hashOf failed to compile because of different
inheritance order in DMD 2.097.1
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: critical
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: bitwo...@qq.com

Compiler: DMD 2.097.1

Error: 

```
../../src/druntime/import/core/internal/hash.d(612,33): Error: expected 2
arguments for `getMember` but had 1
source/app.d(30,26): Error: template instance
`core.internal.hash.hashOf!(Bug!string)` error instantiating
```

Test Code:

```
import std.range;

interface IObject {
size_t toHash() @trusted nothrow;
}

interface Bug(E) : InputRange!E, IObject {

}

interface OK(E) : IObject, InputRange!E {
}


void main() {

{
Bug!string s;
size_t t = hashOf(s);
}


{
OK!string s;
size_t t = hashOf(s);
}
}
```

--

[Issue 22076] hashOf(S) can segfault if S.toHash is forwarded via 'alias this' to a receiver which may be null

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22076

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Dlang Bot  ---
dlang/druntime pull request #3501 "[stable] hashOf(S) can segfault if S.toHash
is forwarded via 'alias this' to a receiver which may be null" was merged into
stable:

- 3b861301cfe1dbe3e4a02093312e6f2c68454daa by Nathan Sashihara:
  Fix 22076 - hashOf(S) can segfault if S.toHash is forwarded via 'alias this'
to a receiver which may be null

https://github.com/dlang/druntime/pull/3501

--

[Issue 22076] hashOf(S) can segfault if S.toHash is forwarded via 'alias this' to a receiver which may be null

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22076

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Dlang Bot  ---
@n8sh created dlang/druntime pull request #3501 "[stable] hashOf(S) can
segfault if S.toHash is forwarded via 'alias this' to a receiver which may be
null" fixing this issue:

- Fix 22076 - hashOf(S) can segfault if S.toHash is forwarded via 'alias this'
to a receiver which may be null

https://github.com/dlang/druntime/pull/3501

--

[Issue 22076] New: hashOf(S) can segfault if S.toHash is forwarded via 'alias this' to a receiver which may be null

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22076

  Issue ID: 22076
   Summary: hashOf(S) can segfault if S.toHash is forwarded via
'alias this' to a receiver which may be null
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

Demonstration:

---
void main()
{
struct S
{
Object a;
alias a this;
}

cast(void) .object.hashOf(S.init); // Segfaults.
}
---

--

[Issue 22024] hashOf does not work on enum types whose base type is a SIMD vector

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22024

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Dlang Bot  ---
dlang/druntime pull request #3497 "[stable] hashOf does not work on enum types
whose base type is a SIMD vector" was merged into stable:

- 4aa8c47d8fee3f2389dcb4408412a307d15b0393 by Nathan Sashihara:
  Fix Issue 22024 - hashOf does not work on enum types whose base type is a
SIMD vector

  Also incidentally do not pass vector by ref to toHash

https://github.com/dlang/druntime/pull/3497

--

[Issue 22024] hashOf does not work on enum types whose base type is a SIMD vector

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22024

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Dlang Bot  ---
@n8sh created dlang/druntime pull request #3497 "[stable] hashOf does not work
on enum types whose base type is a SIMD vector" fixing this issue:

- Fix Issue 22024 - hashOf does not work on enum types whose base type is a
SIMD vector

  Also incidentally do not pass vector by ref to toHash

https://github.com/dlang/druntime/pull/3497

--

[Issue 22024] New: hashOf does not work on enum types whose base type is a SIMD vector

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=22024

  Issue ID: 22024
   Summary: hashOf does not work on enum types whose base type is
a SIMD vector
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

Does not compile:

---
void main()
{
import core.simd : float4;
enum E : float4 { a = float4.init, }
cast(void) hashOf(E.init);
}
---

--

[Issue 21947] New: RedBlackTree and hashOf do not play well together

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21947

  Issue ID: 21947
   Summary: RedBlackTree and hashOf do not play well together
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: deadal...@gmail.com

See https://run.dlang.io/is/0oIsaQ

struct S {
S[] childs;

int opCmp(const ref S rhs) const {
if (childs.length != rhs.childs.length) {
return cast(int) (childs.length - rhs.childs.length);
}

foreach (const ref c; childs) {
// ...
}

return 0;
}
}

import std.container.rbtree;
alias SSet = RedBlackTree!S;

Which fails with the following error:

/dlang/dmd/linux/bin64/../../src/phobos/std/container/rbtree.d(1113): Error:
`@safe` function `std.container.rbtree.RedBlackTree!(S, "a < b",
false).RedBlackTree.toHash` cannot call `@system` function
`core.internal.hash.hashOf!(S).hashOf`
/dlang/dmd/linux/bin64/../../src/druntime/import/core/internal/hash.d(521):
   `core.internal.hash.hashOf!(S).hashOf` is declared here
/dlang/dmd/linux/bin64/../../src/phobos/std/container/rbtree.d(1113): Error:
function `core.internal.hash.hashOf!(S).hashOf` is not `nothrow`
/dlang/dmd/linux/bin64/../../src/phobos/std/container/rbtree.d(1107): Error:
`nothrow` function `std.container.rbtree.RedBlackTree!(S, "a < b",
false).RedBlackTree.toHash` may throw
onlineapp.d(18): Error: template instance
`std.container.rbtree.RedBlackTree!(S, "a < b", false)` error instantiating

Apparently, the auto-generated hashOf isn't nothrow, while RedBlackTree is.

It is a bit puzzling why these constraints are in place. Changing childs to be
an int[] instead, for instance, works.

I'm not sure is RedBlackTree has unrealistic expectation when it comes to the
provided hash method, or if the autogenerated one is wrong, but it seems to be
a problem to me that elements all provided by phobos to not fit together.

--

[Issue 21642] [REG 2.084] hashOf will fail to compile for some structs/unions that recursively contain shared enums

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21642

--- Comment #3 from Dlang Bot  ---
dlang/druntime pull request #3388 "merge stable" was merged into master:

- 150823db4d2504172a3e84b50487f52cb1210e2b by Nathan Sashihara:
  Fix Issue 21642 - [REG 2.084] hashOf will fail to compile for some
structs/unions that recursively contain shared enums

https://github.com/dlang/druntime/pull/3388

--

[Issue 21642] [REG 2.084] hashOf will fail to compile for some structs/unions that recursively contain shared enums

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21642

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Dlang Bot  ---
dlang/druntime pull request #3376 "[REG 2.084] hashOf will fail to compile for
some structs/unions that recursively contain shared enums" was merged into
stable:

- 1256439d8782412b5dfc00b6a828ac5971065f1e by Nathan Sashihara:
  Fix Issue 21642 - [REG 2.084] hashOf will fail to compile for some
structs/unions that recursively contain shared enums

https://github.com/dlang/druntime/pull/3376

--

[Issue 21642] [REG 2.084] hashOf will fail to compile for some structs/unions that recursively contain shared enums

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21642

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Dlang Bot  ---
@n8sh created dlang/druntime pull request #3376 "[REG 2.084] hashOf will fail
to compile for some structs/unions that recursively contain shared enums"
fixing this issue:

- Fix Issue 21642 - [REG 2.084] hashOf will fail to compile for some
structs/unions that recursively contain shared enums

https://github.com/dlang/druntime/pull/3376

--

[Issue 21642] New: [REG 2.084] hashOf will fail to compile for some structs/unions that recursively contain shared enums

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21642

  Issue ID: 21642
   Summary: [REG 2.084] hashOf will fail to compile for some
structs/unions that recursively contain shared enums
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

The following code compiles with DMD 2.067.1 to 2.083.1 but fails to compile on
2.084.1:

---
void main()
{
enum C : char { _ = 1, }
union U { C c; void[0] _; }
shared union V { U u; }
cast(void) hashOf(V.init);
}
---

The underlying issue is a problem with the CTFE path for getting the byte
representation of shared enum members. The following code has never compiled
but that only became a problem after 2.084:

---
void main()
{
import core.internal.convert : toUbyte;
enum C : char { _ = 1, }
shared C c;
cast(void) toUbyte(c);
}
---

--

[Issue 19568] hashOf should not unnecessarily call a struct's fields' postblits & dtors in CTFE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19568

Nathan S.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Nathan S.  ---
Should have auto-closed.

--

[Issue 21005] Speed up hashOf for associative arrays

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21005

--- Comment #1 from Dlang Bot  ---
@n8sh created dlang/druntime pull request #3147 "Issue 21005 - Speed up hashOf
for associative arrays" mentioning this issue:

- Issue 21005 - Speed up hashOf for associative arrays

https://github.com/dlang/druntime/pull/3147

--

[Issue 21005] New: Speed up hashOf for associative arrays

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=21005

  Issue ID: 21005
   Summary: Speed up hashOf for associative arrays
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

Current code:
---
size_t h = 0;
foreach (key, ref val; aa)
{
size_t[2] hpair;
hpair[0] = key.hashOf();
hpair[1] = val.hashOf();
h += hpair.hashOf();
}
---

Proposed code:
---
size_t h = 0;
foreach (ref key, ref val; aa)
h += hashOf(hashOf(val), hashOf(key));
---

On a 32-bit machine the old code is equivalent to:
---
size_t h = 0;
foreach (key, ref val; aa)
{
size_t k = hashOf(hashOf(key), 0);
k = hashOf(hashOf(val), h);
k = fmix32(k ^ (size_t.sizeof * 2)); // fmix32 being the MurmurHash3
finalizer.
h += k;
}
---

On a 64-bit machine the work involved is greater. That level of mixing at each
step is excessive.

Note:
Writing `hashOf(val, hashOf(key))` might seem better than `hashOf(hashOf(key),
hashOf(key))` as it possibly avoids redundancy, but that can't be used by the
TypeInfo-based hash in rt.aaA._aaGetHash.

--

[Issue 15111] hashOf fails for structs that have an alias this to a dynamic array

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15111

Basile-z  changed:

   What|Removed |Added

 CC|b2.t...@gmx.com |

--

[Issue 20034] [Reg 2.087.0] hashOf of a non-scalar enum doesn't compile

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=20034

Radu Racariu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 20034] [Reg 2.087.0] hashOf of a non-scalar enum doesn't compile

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=20034

--- Comment #1 from Radu Racariu  ---
Addressed in https://github.com/dlang/druntime/pull/2670

--

[Issue 20034] New: [Reg 2.087.0] hashOf of a non-scalar enum doesn't compile

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=20034

  Issue ID: 20034
   Summary: [Reg 2.087.0] hashOf of a non-scalar enum doesn't
compile
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: radu.raca...@gmail.com

The following:
```
import std.stdio;

enum Algo
{
a = "foo",
b = "bar",
c = "baz"
}

void main()
{
writeln(hashOf(Algo.a, 1));
}
```

Produces an error:
/dlang/dmd/linux/bin64/../../src/druntime/import/core/internal/hash.d(135):
Error: undefined identifier e_val, did you mean variable val?
onlineapp.d(14): Error: template instance `core.internal.hash.hashOf!(Algo)`
error instantiating

--

[Issue 19568] hashOf should not unnecessarily call a struct's fields' postblits & dtors in CTFE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19568

--- Comment #1 from Nathan S.  ---
Pull request: https://github.com/dlang/druntime/pull/2453

--

[Issue 19568] New: hashOf should not unnecessarily call a struct's fields' postblits & dtors in CTFE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19568

  Issue ID: 19568
   Summary: hashOf should not unnecessarily call a struct's
fields' postblits & dtors in CTFE
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

Example of code that doesn't work because a CTFE-only path in hashOf
unnecessarily calls an impure destructor and tries to call a disabled postblit:

---
void main()
{
static struct S1
{
@disable this(this);

~this() @nogc nothrow
{
import core.stdc.stdio;
if (mptr) puts("impure");
}

size_t[2] pad;
void* mptr;
}

static struct S2
{
@disable this(this);

~this() @nogc nothrow
{
import core.stdc.stdio;
if (fd != -1) puts("impure");
}

int fd = -1;
S1 s1;
}

static struct S3
{
private S2 s2;
}

S3 s3;
size_t h = ((ref S3 s3) pure => hashOf(s3))(s3);
}
---

--

Polymorphic hashOf

[Per Nordlöw via Digitalmars-d-learn]

If I want to include the class type (TypeInfo) inside a class 
instance hash, is the following snippet a good `@safe pure 
nothrow @nogc`-solution?:



import core.internal.hash : hashOf;

/** Hash that distinguishes `Expr(X)` from `NounExpr(X)`. */
hash_t hashOfPolymorphic(Class)(Class aClassInstance) @trusted 
pure nothrow @nogc

if (is(Class == class))
{
assert(Class.alignof == 8);
return (cast(hash_t)(cast(void*)typeid(Class)) >> 3) ^ 
hashOf(aClassInstance);

}

class Thing
{
}

class Expr : Thing
{
@safe pure nothrow @nogc:
alias Data = string;
this(Data data)
{
this.data = data;
}
@property override hash_t toHash() const @safe pure nothrow 
@nogc

{
return hashOf(data);
}
Data data;
}

class NounExpr : Expr
{
@safe pure nothrow @nogc:
this(Data data)
{
super(data);
}
@property override hash_t toHash() const @safe pure nothrow 
@nogc

{
return hashOf(data);
}
}

class Year : Thing
{
@safe pure nothrow @nogc:
alias Data = long;
@property override hash_t toHash() const @safe pure nothrow 
@nogc

{
return hashOf(data);
}
Data data;
}

@safe pure nothrow unittest
{
auto car1 = new Expr("car");
auto car2 = new Expr("car");
auto bar1 = new Expr("bar");
auto ncar = new NounExpr("car");

void testEqual() @safe pure nothrow @nogc
{
assert(hashOf(car1) == hashOf(car2));
assert(hashOfPolymorphic(car1) == 
hashOfPolymorphic(car2));

}

void testDifferent1() @safe pure nothrow @nogc
{
assert(hashOf(car1) != hashOf(bar1));
assert(hashOfPolymorphic(car1) != 
hashOfPolymorphic(bar1));

}

void testDifferent2() @safe pure nothrow @nogc
{
assert(hashOf(car1) == hashOf(ncar));
assert(hashOfPolymorphic(car1) != 
hashOfPolymorphic(ncar));

}

testEqual();
testDifferent1();
testDifferent2();
}

[Issue 19197] Replace instances of typeid(T).getHash(..) with hashOf

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19197

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/f784f74dada2f64153ed52243fa46a5156897547
Fix Issue 19197 - Replace instances of typeid(T).getHash(..) with hashOf

https://github.com/dlang/phobos/commit/f626143a43b7a5312ba28ab57ab2351da23960c9
Merge pull request #6699 from n8sh/issue-19197

Fix Issue 19197 - Replace instances of typeid(T).getHash(..) with hashOf
merged-on-behalf-of: Nathan Sashihara 

--

[Issue 19197] Replace instances of typeid(T).getHash(..) with hashOf

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19197

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 19332] hashOf fails to compile for const struct that has non-const toHash & has all fields bitwise-hashable

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19332

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 19332] hashOf fails to compile for const struct that has non-const toHash & has all fields bitwise-hashable

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19332

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/d380bccfb1629dc99c23cc5d8d668e72d267a34c
Fix Issue 19332 - hashOf fails to compile for const struct that has non-const
toHash & has all fields bitwise-hashable

--

[Issue 19332] hashOf fails to compile for const struct that has non-const toHash & has all fields bitwise-hashable

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19332

--- Comment #1 from Nathan S.  ---
Pull request: https://github.com/dlang/druntime/pull/2337

--

[Issue 19332] hashOf fails to compile for const struct that has non-const toHash & has all fields bitwise-hashable

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19332

Nathan S.  changed:

   What|Removed |Added

Summary|hashOf fails for const  |hashOf fails to compile for
   |struct that has non-const   |const struct that has
   |toHash & has all fields |non-const toHash & has all
   |bitwise-hashable|fields bitwise-hashable

--

[Issue 19332] New: hashOf fails for const struct that has non-const toHash & has all fields bitwise-hashable

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19332

  Issue ID: 19332
   Summary: hashOf fails for const struct that has non-const
toHash & has all fields bitwise-hashable
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

Example:

---
struct NotOkay
{
int canBitwiseHashInts;
size_t toHash() /* not const */ { return 0; }
}

struct Okay
{
float cantBitwiseHashFloats;
size_t toHash() /* not const */ { return 0; }
}

void main()
{
const okay = Okay.init;
hashOf(okay); // Compiles but writes a message about the non-callable
toHash.

const notOkay = NotOkay.init;
hashOf(notOkay); // Compilation fails!
}
---

--

[Issue 19197] Replace instances of typeid(T).getHash(..) with hashOf

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19197

Nathan S.  changed:

   What|Removed |Added

 CC||n8sh.second...@hotmail.com

--- Comment #2 from Nathan S.  ---
>Is the return of the hashOf different that the one for the one for
>the typeid(T).getHash(..)?

It can be.
https://dlang.org/phobos/object.html#.hashOf
>Calculates the hash value of `arg` with an optional `seed` initial
>value. The result might not be equal to `typeid(T).getHash()`.

--

[Issue 19197] Replace instances of typeid(T).getHash(..) with hashOf

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19197

--- Comment #1 from Tiberiu Lepadatu  ---
(In reply to ZombineDev from comment #0)
> Since core.internal.hash.hashOf is a template, there are a number potential
> benefits:
> * better performance (e.g. more opportunities for inlining, less
> indirections for value types)
> * less dependence on TypeInfo (which we want to phase out in the long term)
> * -betterC friendly (no need to link druntime and phobos to your library /
> app, in order to use simple templates like std.typecons.Nullable)

I have started working on this but when I change typeid(T).getHash(..) to
hashOf at line 2682 the unittest is failing. Is the return of the hashOf
different that the one for the one for the typeid(T).getHash(..)?

--

[Issue 19197] Replace instances of typeid(T).getHash(..) with hashOf

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19197

Tiberiu Lepadatu  changed:

   What|Removed |Added

 CC||tiberiulepadat...@gmail.com
   Assignee|nob...@puremagic.com|tiberiulepadat...@gmail.com

--

[Issue 19197] Replace instances of typeid(T).getHash(..) with hashOf

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19197

Eduard Staniloiu  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||edi33...@gmail.com

--

[Issue 18089] AArch64: Need Quadruple float support in CTFE hashOf / core.internal.convert.parse

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18089

Nathan S.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18089] AArch64: Need Quadruple float support in CTFE hashOf / core.internal.convert.parse

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18089

Nathan S.  changed:

   What|Removed |Added

 CC||n8sh.second...@hotmail.com

--- Comment #4 from Nathan S.  ---
Fixed by https://github.com/dlang/druntime/pull/2257

--

[Issue 19262] hashOf associative array should infer nothrow

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19262

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/050ad81f24e1543f409cc0280e9f5d0c81193eea
Fix Issue 19262 - hashOf associative array should infer nothrow

https://github.com/dlang/druntime/commit/f60615f47acd84786c0866a4688e2bdbaf5e7815
Merge pull request #2323 from n8sh/issue-19262

Fix Issue 19262 - hashOf associative array should infer nothrow
merged-on-behalf-of: Nathan Sashihara 

--

[Issue 19262] hashOf associative array should infer nothrow

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19262

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 19282] hashOf segfaults for non-null C++ objects

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19282

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 19282] hashOf segfaults for non-null C++ objects

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19282

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/702e0c1720d59479e669ef38800238ef070166d7
Fix Issue 19282 - hashOf segfaults for non-null C++ objects

https://github.com/dlang/druntime/commit/565690adbbbf57fc8ee29a6d8556f14008143008
Merge pull request #2318 from n8sh/issue-19282

Fix Issue 19282 - hashOf segfaults for non-null C++ objects
merged-on-behalf-of: Nathan Sashihara 

--

[Issue 19262] hashOf associative array should infer nothrow

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19262

--- Comment #1 from Nathan S.  ---
Pull request: https://github.com/dlang/druntime/pull/2323

--

[Issue 19262] hashOf associative array should infer nothrow

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19262

Nathan S.  changed:

   What|Removed |Added

Summary|core.internal.hash.hashOf   |hashOf associative array
   |associative array should|should infer nothrow
   |infer nothrow   |

--

[Issue 19282] hashOf segfaults for non-null C++ objects

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19282

Nathan S.  changed:

   What|Removed |Added

Summary|hashOf segfaults for|hashOf segfaults for
   |non-null C++ objects that   |non-null C++ objects
   |don't inherit from  |
   |object.Object   |

--

[Issue 19282] hashOf segfaults for non-null C++ objects that don't inherit from object.Object

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19282

Nathan S.  changed:

   What|Removed |Added

Summary|hashOf segfaults for|hashOf segfaults for
   |non-null C++ objects and|non-null C++ objects that
   |interfaces  |don't inherit from
   ||object.Object

--

[Issue 19282] hashOf segfaults for non-null C++ objects and interfaces

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19282

--- Comment #1 from Nathan S.  ---
Pull request: https://github.com/dlang/druntime/pull/2318

--

[Issue 19282] New: hashOf segfaults for non-null C++ objects and interfaces

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19282

  Issue ID: 19282
   Summary: hashOf segfaults for non-null C++ objects and
interfaces
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

The following code crashes:

---
extern(C++)
{
class C {}
}

void main()
{
C c = new C();
size_t h = .hashOf(c);
}
---

--

[Issue 19239] New: Fix unsafe casting away of const in hashOf(const Object)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19239

  Issue ID: 19239
   Summary: Fix unsafe casting away of const in hashOf(const
Object)
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

`Object.toHash` is not const. Since a struct's `toHash` needs to be const,
usually a struct will just cast away const-ness of an Object and hope that this
violation of the type system doesn't cause a catastrophe. This happens to be
okay for objects that don't override `toHash` because the base implementation
is based on the object's address and is logically const even though it doesn't
have the `const` attribute. We can make this sound by performing a runtime
check to see if it uses the address-based Object.toHash. (It would be even
better if we could perform a runtime check to see if its overridden with a
const function, but I don't believe that is a way to do this.) Doing this will
let us legitimately call `const(Object).toHash()` in `@trusted` code.

--

[Issue 19204] hashOf doesn't accept SIMD vectors

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19204

--- Comment #1 from Nathan S.  ---
Pull request: https://github.com/dlang/druntime/pull/2289

--

[Issue 19204] hashOf doesn't accept SIMD vectors

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19204

Nathan S.  changed:

   What|Removed |Added

Summary|core.internal.hash.hashOf   |hashOf doesn't accept SIMD
   |doesn't accept SIMD vectors |vectors

--

[Issue 19197] New: Replace instances of typeid(T).getHash(..) with hashOf

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=19197

  Issue ID: 19197
   Summary: Replace instances of typeid(T).getHash(..) with hashOf
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: petar.p.ki...@gmail.com

Since core.internal.hash.hashOf is a template, there are a number potential
benefits:
* better performance (e.g. more opportunities for inlining, less indirections
for value types)
* less dependence on TypeInfo (which we want to phase out in the long term)
* -betterC friendly (no need to link druntime and phobos to your library / app,
in order to use simple templates like std.typecons.Nullable)

--

[Issue 16293] hashOf should be @nogc when it can be

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16293

Nathan S.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||n8sh.second...@hotmail.com
 Resolution|--- |DUPLICATE

--- Comment #2 from Nathan S.  ---
This wasn't done before, because the CTFE path wasn't `@nogc`, but now it is.

*** This issue has been marked as a duplicate of issue 19009 ***

--

[Issue 16518] hashOf is @system for dynamic arrays

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16518

Nathan S.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||n8sh.second...@hotmail.com
 Resolution|--- |DUPLICATE

--- Comment #1 from Nathan S.  ---
Fixed.

*** This issue has been marked as a duplicate of issue 18920 ***

--

[Issue 18652] hashOf example doesn't compile

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18652

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18652] hashOf example doesn't compile

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18652

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/41eb363d75f38bace0a9a1f8e39bd5805cd98c61
Fix Issue 18652 - hashOf example doesn't compile

https://github.com/dlang/druntime/commit/11aecf478a6a23dca1cee27fad5dac052cb0e0ba
Merge pull request #2152 from WalterBright/fix18652

Issue 18652 - hashOf example doesn't compile

--

[Issue 18652] hashOf example doesn't compile

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18652

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/druntime/pull/2152

--

[Issue 18652] New: hashOf example doesn't compile

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18652

  Issue ID: 18652
   Summary: hashOf example doesn't compile
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: elpenguin...@gmail.com

The example in the documentation for object.hashOf does not compile.

```
struct Test
{
int a;
string b;
MyObject c;
size_t toHash() const @safe pure nothrow
{
size_t hash = a.hashOf();
hash = b.hashOf(hash);
size_t h1 = c.myMegaHash();
hash = h1.hashOf(hash); //Mix two hash values
return hash;
}
}
```
This is entirely due to it being marked @safe, while hashOf(string) is @system.

This example should be made into a documented unittest and corrected.

--

[Issue 15111] hashOf fails for structs that have an alias this to a dynamic array

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15111

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to dmd-cxx at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/3af285fea29e7bbe2bea9b4fcb4b93f1ecb72755
fix issue 15111 - hashOf fails for structs that have an alias this to a dynamic
array

https://github.com/dlang/druntime/commit/2d8b0a5901bde46d3f773ad1a22cd3780306067c
Merge pull request #1536 from BBasile/issue-15111

--

[Issue 18089] AArch64: Need Quadruple float support in CTFE hashOf / core.internal.convert.parse

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18089

--- Comment #3 from Iain Buclaw  ---
So from a CTFE standpoint, its support cent/ucent, or support unions.

--

[Issue 18089] AArch64: Need Quadruple float support in CTFE hashOf / core.internal.convert.parse

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18089

--- Comment #2 from Johannes Pfau  ---
Yes, it's a more advanced issue. From a cursory look I'd say the algorithm /
approach should work for quadruple floats as well. However, every temporary
variable has to be checked whether the data type is large enough for quadruple
floats. I think this is the case for everything except for the mantissa, which
does not fit into an ulong. Maybe we can simply use a ulong[2] in the Float
struct, then fix shiftrRound.

However, I think there were efforts in phobos to introduce a generic
FloatTraits type which may also be applicable here and avoids some code
duplication? It is also quite sad, that 600 lines in the convert module are
required for CTFE, whereas a few lines of union/cast code suffices for
runtime

--

[Issue 18089] AArch64: Need Quadruple float support in CTFE hashOf / core.internal.convert.parse

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18089

Steven Schveighoffer  changed:

   What|Removed |Added

 CC|schvei...@yahoo.com |

--- Comment #1 from Steven Schveighoffer  ---
This is out of my league, sorry!

--

[Issue 18089] AArch64: Need Quadruple float support in CTFE hashOf / core.internal.convert.parse

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18089

Johannes Pfau  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org,
   ||schvei...@yahoo.com

--

[Issue 18089] AArch64: Need Quadruple float support in CTFE hashOf / core.internal.convert.parse

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18089

Johannes Pfau  changed:

   What|Removed |Added

 CC||c...@dawg.eu,
   ||johannesp...@gmail.com

--

[Issue 18089] New: AArch64: Need Quadruple float support in CTFE hashOf / core.internal.convert.parse

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18089

  Issue ID: 18089
   Summary: AArch64: Need Quadruple float support in CTFE hashOf /
core.internal.convert.parse
   Product: D
   Version: D2
  Hardware: Other
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: johannesp...@gmail.com

The core.internal.convert.parse function does currently not support the
'Quadruple' float format, which is used for the real type on AArch64.

Non-CTFE code seems to be suppoerted, but for CTFE this means that hashOf won't
work for reals on AArch64 targets. AFAICS this does not cause a problem when
compiling druntime / phobos, but when compiling the unittests, one test in
core.internal.hash causes a compile time failure:

enum raexpr = [8.99L+86i, 3.12L+99i, 5.66L+12i];
enum h29 = raexpr.hashOf();

So this blocks proper CI testing on AArch64 (as a compile failure when
compiling the tests obviously prevent us from doing any kind of regression
testing)

--

Re: How do you call hashOf() on a string?

[Enjoys Math via Digitalmars-d-learn]

Changing @safe to @system worked.  IDK, but w/e! ;-)

How do you call hashOf() on a string?

[Enjoys Math via Digitalmars-d-learn]

module smallest_grammar;
import std.conv;
import std.algorithm;

struct Symbol(T) {
public:
this(T sym, bool isVar) {
this.sym = sym;
this.is_var = isVar;
}

@property T symbol() { return sym; }
@property bool isVar() { return is_var; }


private:
T sym;
bool is_var = false;
}


struct String(T) {
public:
this(const T[] s) {
this.s = s.dup;
}

alias s this;

string toString() const { return to!string(s); }
	string flattened() const { string t = "";  foreach (c; s)	t ~= 
to!string(c);  return t; }


size_t toHash() const @safe pure nothrow
{
return flattened().hashOf();
}

bool opEquals(ref const String t) const @safe pure nothrow
{
if (t.length != this.length)
return false;

for(size_t k=0; k < t.length; k++)
if (t.s[k] != this.s[k]) return false;

return true;
}


private
T[] s;
}

-


My hash function:

size_t toHash() const @safe pure nothrow
{
return flattened().hashOf();
}

-

Is yielding:
smallest_grammar.d(35): Error: @safe function 
'smallest_grammar.String!string.String.toHash' cannot call 
@system function 'object.hashOf!string.hashOf'

[Issue 16654] hashOf returns different hashes for the same string value

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16654

--- Comment #7 from github-bugzi...@puremagic.com ---
Commit pushed to newCTFE at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc
Revert object.hashOf changes from "use array interface to hashOf()"

fixes issues 16654 & 16764.

--

[Issue 16764] `hashOf` is misleading, error-prone, and useless

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16764

--- Comment #7 from github-bugzi...@puremagic.com ---
Commit pushed to newCTFE at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc
Revert object.hashOf changes from "use array interface to hashOf()"

--

[Issue 16654] hashOf returns different hashes for the same string value

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16654

--- Comment #6 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc
Revert object.hashOf changes from "use array interface to hashOf()"

--

[Issue 16764] `hashOf` is misleading, error-prone, and useless

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16764

--- Comment #6 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc
Revert object.hashOf changes from "use array interface to hashOf()"

--

[Issue 16654] hashOf returns different hashes for the same string value

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16654

--- Comment #5 from github-bugzi...@puremagic.com ---
Commit pushed to scope at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc
Revert object.hashOf changes from "use array interface to hashOf()"

--

[Issue 16764] `hashOf` is misleading, error-prone, and useless

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16764

--- Comment #5 from github-bugzi...@puremagic.com ---
Commit pushed to scope at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc
Revert object.hashOf changes from "use array interface to hashOf()"

--

[Issue 16973] `hashOf` has error-prone signature as `(T, seed)` may be confused with `(ptr, length)`

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16973

--- Comment #4 from Denis Shelomovskii <verylonglogin@gmail.com> ---
(In reply to safety0ff.bugz from comment #3)
> (In reply to Denis Shelomovskii from comment #1)
> > This issue caused druntime Issue 16974.
> 
> Druntime used to have a function rt.util.hash.hashOf with signature:
> size_t hashOf( const(void)* buf, size_t len, size_t seed )
> 
> Which made up most references to 'hashOf' within druntime (by TypeInfos.)
> 
> I wouldn't be surprised if this bug was due to thinking it's calling
> rt.util.hash.hashOf instead of object.hashOf.
> 
> Mistaking core.internal.hash.hashOf for rt.util.hash.hashOf was responsible
> for a recent regression.

No doubts it's a function call from wrong module. But it doesn't change the
fact that Issue 16974 is caused by this issue.

--

[Issue 16973] `hashOf` has error-prone signature as `(T, seed)` may be confused with `(ptr, length)`

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16973

safety0ff.bugz <safety0ff.b...@gmail.com> changed:

   What|Removed |Added

 CC||safety0ff.b...@gmail.com

--- Comment #3 from safety0ff.bugz <safety0ff.b...@gmail.com> ---
(In reply to Denis Shelomovskii from comment #1)
> This issue caused druntime Issue 16974.

Druntime used to have a function rt.util.hash.hashOf with signature:
size_t hashOf( const(void)* buf, size_t len, size_t seed )

Which made up most references to 'hashOf' within druntime (by TypeInfos.)

I wouldn't be surprised if this bug was due to thinking it's calling
rt.util.hash.hashOf instead of object.hashOf.

Mistaking core.internal.hash.hashOf for rt.util.hash.hashOf was responsible for
a recent regression.

--

[Issue 16973] `hashOf` has error-prone signature as `(T, seed)` may be confused with `(ptr, length)`

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16973

--- Comment #2 from Denis Shelomovskii <verylonglogin@gmail.com> ---
A possible solution is to require explicit second argument type specification.

Using current language abilities it can be done with helper `seed` function or
struct:
---
hashOf(obj, seed(0));
---
or with function overload rename:
---
hashOfWithSeed(obj, 0);
---

--

[Issue 16973] `hashOf` has error-prone signature as `(T, seed)` may be confused with `(ptr, length)`

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16973

--- Comment #1 from Denis Shelomovskii  ---
This issue caused druntime Issue 16974.

--

[Issue 16764] `hashOf` is misleading, error-prone, and useless

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16764

--- Comment #4 from Denis Shelomovskii  ---
So #1 and #3 are solved by the pull, but #2 still stays. Opened Issue 16973 for
it.

--

[Issue 16973] New: `hashOf` has error-prone signature as `(T, seed)` may be confused with `(ptr, length)`

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16973

  Issue ID: 16973
   Summary: `hashOf` has error-prone signature as `(T, seed)` may
be confused with `(ptr, length)`
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: verylonglogin@gmail.com

In our root `object` module we have a function `hashOf` [1] which accept any
type as the first parameter and optional seed as the second parameter.

This function signature is error-prone because its signature allows this
incorrect usage:
---
hashOf(arr.ptr, arr.length); // hash of ptr with seed set to length
---

It's a major issue as (ptr, length) usage pattern is common in programming and
incorrect hash function behavior is hard to debug.


[1] http://dlang.org/phobos/object.html#.hashOf

--

[Issue 16764] `hashOf` is misleading, error-prone, and useless

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16764

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc
Revert object.hashOf changes from "use array interface to hashOf()"

--

[Issue 16654] hashOf returns different hashes for the same string value

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16654

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc
Revert object.hashOf changes from "use array interface to hashOf()"

--

[Issue 16654] hashOf returns different hashes for the same string value

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16654

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 16654] hashOf returns different hashes for the same string value

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16654

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc
Revert object.hashOf changes from "use array interface to hashOf()"

fixes issues 16654 & 16764.

--

[Issue 16764] `hashOf` is misleading, error-prone, and useless

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16764

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 16764] `hashOf` is misleading, error-prone, and useless

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16764

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc
Revert object.hashOf changes from "use array interface to hashOf()"

fixes issues 16654 & 16764.

--

[Issue 16764] `hashOf` is misleading, error-prone, and useless

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16764

joeyemm...@yahoo.com changed:

   What|Removed |Added

 CC||joeyemm...@yahoo.com

--- Comment #1 from joeyemm...@yahoo.com ---
Worst part is hashOf used to not work this way, got changed to cast to void[]
when before is just called core.internal.hash.hashOf without messing with the
input. The change is breaking and seems horribly wrong. Seems walter made the
change.

https://github.com/dlang/druntime/commit/267fa2a06289c04200f720019050e7387f5e5a00

--

[Issue 16764] New: `hashOf` is misleading, error-prone, and useless

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16764

  Issue ID: 16764
   Summary: `hashOf` is misleading, error-prone, and useless
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: verylonglogin@gmail.com

In our root `object` module we have a function `hashOf` [1] with correct
definition: "to calculate hash of raw byte representation of given object" (at
posting time, see [2]).

This function should not be there because:
1. It is misleading (and as a result error-prone) because user doesn't expect
that logical object structure is not considered and this function operates with
raw representation bytes.
2. Has signature allowing incorrect usage (and as a result the function is
extremely error-prone).
3. It is not generally useful because primary purpose of hash functions is to
calculate hash of byte array with dynamic length (`void[]`) and this function
only accept data with size known at compilation time.

The code illustrating the issue (#1 and #2 from list above):
---
void main()
{
// #1:
hashOf(5); // #1: hash of raw int bytes, different on different systems
real r;
hashOf(r); // #1: hash of raw bytes of real including padding
hashOf(MyStruct()); // #1: hash of raw bytes of struct including padding
and ignoring `toHash` function
int[] arr = [1];
hashOf(arr); // #1: hash of raw bytes of ptr+length
    assert(hashOf(arr) == hashOf([1])); // #1: as a result this fails

// #2:
hashOf(arr.ptr, arr.length); // #2: hash of raw bytes of ptr with seed set
to length
}
---

[1] http://dlang.org/phobos/object.html#.hashOf
[2]
https://github.com/dlang/druntime/blob/7962fb8acaeb0008c531d1ae170cd15ff59558ea/src/object.d#L3203

--