You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mixin has some handling for re-entrant class loading that was originally designed to catch issues in LW transformers. These days, that is not much of an issue but what is a fairly common issue is misbehaving IMixinConfigPlugin implementations that cause re-entrant class loads (as seen recently in FrozenBlock/WilderWild#289).
These issues can be non-obvious and require a fair bit of effort to trace down when they do occur, since there isn't a clear blame trail. I unfortunately haven't had the time to investigate the lack of logging fully, but my running hunch is that because Mixin is still in its prepare phase when querying config plugins, the list of pending mixins has not yet been populated for it to know that it's loading a class that would have Mixins applied -- perhaps the re-entrancy check could be made more string during preparation, or the Mixin targets under consideration could be checked.
I doubt upstream behavior is different, but I haven't had a chance to validate that either unfortunately so I'm reporting here first.
Long-term i'd like to see some sort of annotation-driven or data-driven conditional mixin system, to replace hand-rolled and error-prone systems that individual modders create with limited testing (as happened with Wilder Wild) -- that would remove this potential footgun for modders.
The text was updated successfully, but these errors were encountered:
Mixin has some handling for re-entrant class loading that was originally designed to catch issues in LW transformers. These days, that is not much of an issue but what is a fairly common issue is misbehaving
IMixinConfigPlugin
implementations that cause re-entrant class loads (as seen recently in FrozenBlock/WilderWild#289).These issues can be non-obvious and require a fair bit of effort to trace down when they do occur, since there isn't a clear blame trail. I unfortunately haven't had the time to investigate the lack of logging fully, but my running hunch is that because Mixin is still in its prepare phase when querying config plugins, the list of pending mixins has not yet been populated for it to know that it's loading a class that would have Mixins applied -- perhaps the re-entrancy check could be made more string during preparation, or the Mixin targets under consideration could be checked.
I doubt upstream behavior is different, but I haven't had a chance to validate that either unfortunately so I'm reporting here first.
Long-term i'd like to see some sort of annotation-driven or data-driven conditional mixin system, to replace hand-rolled and error-prone systems that individual modders create with limited testing (as happened with Wilder Wild) -- that would remove this potential footgun for modders.
The text was updated successfully, but these errors were encountered: