Fix static AA initialization

[schveiguy]

Static AA initialization (the yet unreleased feature, added in #15468) is broken for some cases of AA initialization.

The issue comes from TypeInfo.getHash not always behaving the same as hashOf. The fix here is to add a delegate which does the hashing to the Impl struct of the AA. Normal AA initialization at runtime copies the key's TypeInfo.getHash function, whereas when we initialize it using static AA initialization, we write our own function that always uses hashOf, making the hashing consistent.

FWIW, this means some cases where the compiler passes in the key TypeInfo are not needed, though we still call opEquals from the key TypeInfo. Possibly we can remove that usage by storing all the delegates needed upon creation.

[dlang-bot]

Thanks for your pull request, @schveiguy!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "stable + dmd#15744"

[schveiguy]

ping @dkorpel This is going to fail unittests, and I don't know why. I couldn't get it to pass on my local system with a double[2] key.

[maxhaton]

Is there a bugzilla?

[schveiguy]

As this is a new unreleased feature, I am unsure if it's a bug or not. I'm hoping @dkorpel can shed some light.

[schveiguy]

Hm... an issue with the current DMD tests, I'll investigate.

[schveiguy]

Added this because I had to make this @trusted. Note that we can pretty much ignore all attributes because this is CTFE only.

[schveiguy]

Anyone have any idea why this would be bad? The default of hashing the pointer seems ludicrous to me -- the pointer comes from anywhere and is a consequence of having a runtime interface vs. a compile time one. It has nothing to do with item equality or hashing.

[dkorpel]

It could be a bad performance regression, not sure if anyone actually relies on it though.

[schveiguy]

OK, finally this is the thing that fails on my local system.

If I move the static AA declaration outside the unittest, I get the error:

src/core/internal/newaa.d(158): Error: non-constant expression `[1.0, 2.0][0..2]`

[schveiguy]

OK, I found a test that actually compiles and tests the change. unfortunately, it only works if I declare a global (this will be a different bug filed) instead of a static variable. So that's why I put in the version(unittest).

If this turns green, I think it's good to go.

[schveiguy]

What is this error with profilegc? What is the problem, and how do I fix it?

EDIT: I figured it out, and added a readme to help future me or others understand the issues.

[ibuclaw]

Suggested change

	version(unittest):
	struct Foo {
	ubyte x;
	double d;
	}
	int[Foo] utaa = [Foo(1, 2.0) : 5];
	unittest {
	unittest
	{
	static struct Foo
	{
	ubyte x;
	double d;
	}
	static int[Foo] utaa = [Foo(1, 2.0) : 5];

[schveiguy]

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

[dkorpel]

I'll look into it

[dkorpel]

#15774

[schveiguy]

@ibuclaw if you can hold off until this is merged to do the big merge, that would be good. I expect this to turn green.

[ibuclaw]

@ibuclaw if you can hold off until this is merged to do the big merge, that would be good. I expect this to turn green.

You can always just set the base to stable. :-)

[schveiguy]

Just ping me if you do it before this is merged.

[ibuclaw]

Just ping me if you do it before this is merged.

I'm just starting off a final point release of stable, should occupy a couple hours before freezing master for 2.106 beta

[schveiguy]

FWIW, I can't target stable with this until master is merged into stable, because I need Dennis' changes to the newaa as a base.

[schveiguy]

Waiting for merge to stable, then I will retarget stable.

[ibuclaw]

@schveiguy I've changed base of this PR to stable.

[schveiguy]

OK, if nobody reviews this, I guess just merge it in 48 hours?