Skip to content

Type matching issue in registry context introduced in entt 3.16.0 #1310

Open
Open
Type matching issue in registry context introduced in entt 3.16.0#1310
Assignees
skypjackcopilot-swe-agent
Labels
bugaccepted bugssolvedavailable upstream or in a branch

Description

@jdumas
jdumas
opened on Jan 21, 2026

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.

Activity

  1. skypjack
    self-assigned this
    on Jan 26, 2026
  2. skypjack
    added
    triagepending issue, PR or whatever
    on Jan 26, 2026

  3. skypjack commented on Jan 26, 2026

    @skypjack
    skypjack
    on Jan 26, 2026
    Owner

    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.

  4. jdumas commented on Jan 26, 2026

    @jdumas
    jdumas
    on Jan 26, 2026
    Author

    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.

  5. timmyL17 commented on Jan 27, 2026

    @timmyL17
    timmyL17
    on Jan 27, 2026
    Contributor

    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?

  6. skypjack commented on Jan 30, 2026

    @skypjack
    skypjack
    on Jan 30, 2026
    Owner

    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.

  7. skypjack
    assigned
    Copilot
    on Oct 1, 2026
  8. Copilot
    linked a pull request that will close this issueRestore cross-translation-unit type matching in `basic_any` #1354on Oct 1, 2026
  9. skypjack
    added 3 commits that reference this issue on Oct 23, 2026

    test: common class to mimic type hash mismatch - see #1310

    897c405

    test: try to mimic the issue in #1310

    16186de

    any: fallback for type hash mismatch cases - close #1310

    139d618
  10. skypjack
    added
    bugaccepted bugs
    solvedavailable upstream or in a branch
    and removed
    triagepending issue, PR or whatever
    on Oct 23, 2026

  11. skypjack commented on Oct 23, 2026

    @skypjack
    skypjack
    on Oct 23, 2026
    Owner

    Hello. Can you double check the submitted fix? The version on the wip branch should work fine and get you covered. Thanks. 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugaccepted bugssolvedavailable upstream or in a branch

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions