{"action":"created","issue":{"url":"https://api.github.com/repos/MinecraftForge/MinecraftForge/issues/3043","repository_url":"https://api.github.com/repos/MinecraftForge/MinecraftForge","labels_url":"https://api.github.com/repos/MinecraftForge/MinecraftForge/issues/3043/labels{/name}","comments_url":"https://api.github.com/repos/MinecraftForge/MinecraftForge/issues/3043/comments","events_url":"https://api.github.com/repos/MinecraftForge/MinecraftForge/issues/3043/events","html_url":"https://github.com/MinecraftForge/MinecraftForge/issues/3043","id":162344800,"number":3043,"title":"[1.10] Unwanted deobfuscation of member fields in derived classes","user":{"login":"Mumfrey","id":1147071,"avatar_url":"https://avatars.githubusercontent.com/u/1147071?v=3","gravatar_id":"","url":"https://api.github.com/users/Mumfrey","html_url":"https://github.com/Mumfrey","followers_url":"https://api.github.com/users/Mumfrey/followers","following_url":"https://api.github.com/users/Mumfrey/following{/other_user}","gists_url":"https://api.github.com/users/Mumfrey/gists{/gist_id}","starred_url":"https://api.github.com/users/Mumfrey/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Mumfrey/subscriptions","organizations_url":"https://api.github.com/users/Mumfrey/orgs","repos_url":"https://api.github.com/users/Mumfrey/repos","events_url":"https://api.github.com/users/Mumfrey/events{/privacy}","received_events_url":"https://api.github.com/users/Mumfrey/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":{"login":"cpw","id":1217211,"avatar_url":"https://avatars.githubusercontent.com/u/1217211?v=3","gravatar_id":"","url":"https://api.github.com/users/cpw","html_url":"https://github.com/cpw","followers_url":"https://api.github.com/users/cpw/followers","following_url":"https://api.github.com/users/cpw/following{/other_user}","gists_url":"https://api.github.com/users/cpw/gists{/gist_id}","starred_url":"https://api.github.com/users/cpw/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cpw/subscriptions","organizations_url":"https://api.github.com/users/cpw/orgs","repos_url":"https://api.github.com/users/cpw/repos","events_url":"https://api.github.com/users/cpw/events{/privacy}","received_events_url":"https://api.github.com/users/cpw/received_events","type":"User","site_admin":false},"assignees":[{"login":"cpw","id":1217211,"avatar_url":"https://avatars.githubusercontent.com/u/1217211?v=3","gravatar_id":"","url":"https://api.github.com/users/cpw","html_url":"https://github.com/cpw","followers_url":"https://api.github.com/users/cpw/followers","following_url":"https://api.github.com/users/cpw/following{/other_user}","gists_url":"https://api.github.com/users/cpw/gists{/gist_id}","starred_url":"https://api.github.com/users/cpw/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cpw/subscriptions","organizations_url":"https://api.github.com/users/cpw/orgs","repos_url":"https://api.github.com/users/cpw/repos","events_url":"https://api.github.com/users/cpw/events{/privacy}","received_events_url":"https://api.github.com/users/cpw/received_events","type":"User","site_admin":false}],"milestone":null,"comments":1,"created_at":"2016-06-26T20:10:52Z","updated_at":"2016-06-26T21:38:41Z","closed_at":null,"body":"I am experiencing a problem with the FML deobfuscating remapper in 1.10 whereby fields in classes which extend from MC base classes are being remapped (effectively, deobfuscated) when they shouldn't be. This only applies to code which is obfuscated to \"notch names\", which all liteloader mods are since I don't have permission to redistribute MCP mappings.\r\n\r\nThe problem is easy to reproduce:\r\n\r\n```java\r\npublic class SomeCustomScreen extends GuiScreen {\r\n\r\n    // Member field with a name matching an obfuscated field in the parent\r\n    protected float a;\r\n\r\n}\r\n```\r\n\r\nWhen the class is loaded, the field `a` will be remapped to `field_175287_a` because a field `a` exists in `GuiScreen`. The type of field is not taken into account, the field can be of any type. I have confirmed that this only happens in 1.10, the latest 1.9.4 build (at time of posting, 1987) does not exhibit this behaviour.\r\n\r\nI'm going to duck under a table before the next part: The practical upshot of this problem is that \"shadow\" fields in notch-obfuscated mixins are getting incorrectly remapped if a field with the same name exists in the superclass. This basically means that if forge is installed the mixin cannot be applied.\r\n\r\nThe reason this is happening is that mixins are run through the transformer chain just like regular classes, this is necessary in particular so that the deobf transformer can remap class and method names inside them. In general, a mixin class will always extend the same superclass as its target, and this means that the deobf remapper is finding the field mappings in the superclass and incorrectly applying the remap to the member field.\r\n\r\nI believe the root cause of this might be [this change](https://github.com/MinecraftForge/MinecraftForge/commit/260be687239b7ba04d6be2f5b9a0ce432f923cf6#diff-9ded99c2c42f0ce086319530fc38780aR270) made in 1.10, which would seem to make the field map check permissive enough to match superclass fields even when the field type is different, though I'm by no means an expert on the FML codebase and it might be a red herring.\r\n\r\nFor the time being I can fix this for the current situation by breaking the superclass relationship with the mixin in question. However it would be great if you're able to address this, since it's possible that it will affect others who have similar mixin code.\r\n\r\nIf you need any further details I'd be happy to provide them, or if you'd prefer that I just PR a fix so that you don't have to waste your time with it then I'm quite happy to do that too.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/MinecraftForge/MinecraftForge/issues/comments/228624561","html_url":"https://github.com/MinecraftForge/MinecraftForge/issues/3043#issuecomment-228624561","issue_url":"https://api.github.com/repos/MinecraftForge/MinecraftForge/issues/3043","id":228624561,"user":{"login":"cpw","id":1217211,"avatar_url":"https://avatars.githubusercontent.com/u/1217211?v=3","gravatar_id":"","url":"https://api.github.com/users/cpw","html_url":"https://github.com/cpw","followers_url":"https://api.github.com/users/cpw/followers","following_url":"https://api.github.com/users/cpw/following{/other_user}","gists_url":"https://api.github.com/users/cpw/gists{/gist_id}","starred_url":"https://api.github.com/users/cpw/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cpw/subscriptions","organizations_url":"https://api.github.com/users/cpw/orgs","repos_url":"https://api.github.com/users/cpw/repos","events_url":"https://api.github.com/users/cpw/events{/privacy}","received_events_url":"https://api.github.com/users/cpw/received_events","type":"User","site_admin":false},"created_at":"2016-06-26T21:38:41Z","updated_at":"2016-06-26T21:38:41Z","body":"Without the highlighted fix, almost no mods would actually load from 1.9.4 into 1.10, since there are a few fields which have had their type changed. I feel that establishing compatibility for forge mods from 1.9.4 matters, so I'm not sure how I can make both camps happy. "}}
{"actor":{"display_login":"cpw"}}