Type matching issue in registry context introduced in entt 3.16.0

[jdumas]

Hi.

I've hit a very elusive bug in EnTT's type matching behavior. I believe it was introduced by the refactoring of entt::any in v3.16.0. It took me some time to pin down a MWE in Godbolt, but I finally got it:

https://godbolt.org/z/95ET9rMdz

• The code works fine if we compile with EnTT 3.15.0
• The code works fine if we compile in Debug mode

Please let me know what are your thoughts on the matter.

[skypjack]

Splitting it across 4 files was an attack on my sanity! 🙂
Is there a specific reason you did this, otherwise it wouldn't reproduce, or is it just for aesthetics?
I can't figure out if I should look at forced instantiations and the like, or if I can simplify the whole thing to debug it.
Let me know. Thanks.

[jdumas]

I think the issue only happens when we have two different translation units, one TU where FooT<uint32_t> is explicitly instantiated (and all its methods are defined), and one TU where only the class definition is available (its methods are declared, but not defined). For some reason this is causing the search of the FooT<uint32_t> * pointer to fail in main.cpp, whereas it succeeds in foo.cpp.

I guess we can simplify the example into two different .cpp (no header...), but I couldn't reproduce it with a single translation unit.

[timmyL17]

It seems that adding
extern template class FooT<uint32_t>; to main.cpp avoids the error.

https://godbolt.org/z/s3Gnj4c6x

So maybe it has something to do with types/functions being resolved before link time, which is when the duplicate instantiations would be removed without the extern template?

[skypjack]

This is what puzzles me:

The code works fine if we compile in Debug mode

I'd expect the same problem in debugging. Really strange. Something to look into, definitely.