[Issue 16973] `hashOf` has error-prone signature as `(T, seed)` may be confused with `(ptr, length)`
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)`
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
https://issues.dlang.org/show_bug.cgi?id=18652 Walter Brightchanged: 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
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
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
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
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
https://issues.dlang.org/show_bug.cgi?id=18089 Steven Schveighofferchanged: 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
https://issues.dlang.org/show_bug.cgi?id=18089 Johannes Pfauchanged: What|Removed |Added CC||ibuc...@gdcproject.org, ||schvei...@yahoo.com --
[Issue 18089] AArch64: Need Quadruple float support in CTFE hashOf / core.internal.convert.parse
https://issues.dlang.org/show_bug.cgi?id=18089 Johannes Pfauchanged: 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
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?
Changing @safe to @system worked. IDK, but w/e! ;-)
How do you call hashOf() on a string?
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
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
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
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
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
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
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)`
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)`
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)`
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)`
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
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)`
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
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
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
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
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
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
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
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
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 --