2.063: AA value type merging issues

[dnadlinger]

The following fragment, extracted from the std.traits unit tests

private struct QualifiedNameTests {
    struct Inner {}
    shared(const(Inner[int])[]) data;
}

fails with Error: cannot create associative array const(Inner)[int], because somehow, Inner in the AA value type is resolved to a Tident instance of Type.

The whole thing is rather sensitive to the qualifiers, but I couldn't find out where the merging goes wrong yet.

[dnadlinger]

The point where a Tident-reliant Type appears is while generating the TypeInfo for the type of data, more specifically, when calling unSharedOf in TypeInfoSharedDeclaration::llvmDefine.

Still not sure what is really going wrong here.

[redstar]

At least some progress. I used this issue as an excuse for not creating the next release...

[dnadlinger]

It is a good excuse indeed, and yes, we need to get this fixed asap.

[dnadlinger]

Another 10 minutes on the bus, another data point: On LDC master, the Type referenced by the TypeInfoSharedDeclaration is shared(const(Inner[int])), whereas on DMD 2.063.2, it is shared(const(Inner)[int]) (note the different position of the const).

[dnadlinger]

@redstar, @AlexeyProkhin: Any idea what could be going wrong here? The best idea I currently have for going about this would be to sprinkle all the type resolution/merging code with debugging code to figure out what the issue is, but I'm not sure I'll have the time to do that in the next few days.

[dnadlinger]

Okay, #484 doesn't solve this, so the odds that it is actually a LDC-only bug in the type merging code are getting lower. Maybe it's a DMD bug, and it's just our constant use of stripModifiers that exposes it.

[UplinkCoder]

Ehm ...
I looks to me as if this could be a lexer/parser issue

Consider the syntax
shared(const(SomeArrayIdentifier[Someindex]))
in that case Inner ist just the Identifier
as opposed to
shared(const(SomeTypeIdentifier)[SomeOtherType])
....
I really don't know any Internals of ldc or llvm
so if this is just nonesense please ignore it :D

[dnadlinger]

@UplinkCoder: Good idea, but unfortunately, it's not that simple. Essentially, Tident is the class types are assigned to before they have been fully analyzed, i.e. still refer just an identifier in the code and not to an actual semantic entity. Eventually, all types should be resolved on their way through the compiler, but for some reason, this isn't.

[dnadlinger]

Fixed in master, although I don't exactly know when.