[REG2.064] Issue 12144 - Unresolved xopEquals when referenced by dynamic array constructor

[9rnsr]

https://d.puremagic.com/issues/show_bug.cgi?id=12144

Run semantic3 for TypeInfo-related struct member functions.

[9rnsr]

OK, ready to review. @MartinNowak how about this?

[MartinNowak]

I think I like my solution better, but I'll have a closer look later.
#3255
If we continue to generate TypeInfo during obj generation, it's too late to run semantic3 on a struct, so generating struct TypeInfo eagerly seems like a more stable fix.

[rainers]

I agree we must not generate type info from the glue code, especially if we want to support RTInfo. I doubt you captured all the places where this happens. See how many places I had to patch to get complete(?) RTInfo:

#2480

[9rnsr]

I agree with that eagerly generating TypeInfo for all types is the most easiest way to fix the issue. But I'm also afraid that doing it will make compilation speed more slower. So I'd like to keep "on-demand" semantic for TypeInfo generation.

This is necessary and sufficient change to fix the regression issue.

[MartinNowak]

Let's at least add an assertion to TypeInfoStructDeclaration::toObjFile which checks that either semantic pass 3 was run for the StructDeclaration or the struct was forward declared.

But I'm also afraid that doing it will make compilation speed more slower.

Why would it? You're outputting a few extra bytes that are most likely needed anyhow. If you generate that on-demand you might need to do it multiple times, have to rerun semantic3 and the linker has to deduplicate it. If someone is using a complex RTInfo it only gets worse.
So I think we should try to get away from vague linkage here, but currently the compiler relies on TypeInfo even when not linking against that struct #3255 (comment).

[MartinNowak]

Auto-merge toggled on

[9rnsr]

Auto-merge toggled off

[9rnsr]

Sorry, please wait a while to merge this. Maybe I completely misunderstand the issue. I'd reconsider the issue.

[MartinNowak]

The issue is fairly simple, sometimes we call TypeInfoStructDeclaration::toObjFile for StructDeclarations which only had semantic2 run. The emitted typeinfo refers to __xOpEquals and __xOpCmp, but semantic3 would have shown that those should be xerreq and xerrcmp.

[9rnsr]

The issue is fairly simple, sometimes we call TypeInfoStructDeclaration::toObjFile for StructDeclarations which only had semantic2 run.

That's right! I didn't understand the issue until now!
And if I understand correctly, we already have a solution. The TypeInfo "codegen" should be done as same as template instances. If a struct is non-root symbol (≒ a template is instantiated only in non-root module), its TypeInfo toObjFile should be elided.

[9rnsr]

Sign... I tried to implement my idea, but currently it would need more work.
9rnsr/dmd@master...fix12144x

So I reverted this PR state.

[MartinNowak]

The TypeInfo "codegen" should be done as same as template instances.

That's roughly my conclusion too, but as Rainer mentioned there are a few problem with structs declared in Deimos, because they don't require linkage.
We could resort to some fallback TypeInfo for those, but it gets kind of complicated.
#3255 (comment)

[9rnsr]

I'll merge this PR so it is necessary for the next release.