I have some generic code in our project that’s started spitting out IL2CPP errors on build. This is a regression, as the code used to work in older versions.
Bug report is #1427322
Specifically, the last version the bug is not present in is:
2020.3.32f1
The bug is present in:
2020.3.33f1
2021.3.0.f1
The bug is not present in 2022.0.1f1, probably due to the changes to IL2CPP there.
The repro project contains four files, which is as far as I managed to strip the project down:
// IHasObject.cs
public interface IHasObject {
object obj { get; }
}
// ShapeTrigger.cs
using UnityEngine;
public class ShapeTrigger<THasObject, TTrigger> : ScriptableObject
where TTrigger : ShapeTrigger<THasObject, TTrigger>
where THasObject : IHasObject {
public ShapeTriggerParent<THasObject, TTrigger> parent;
}
//ShapeTriggerParent.cs
using UnityEngine;
public class ShapeTriggerParent <THasObject, TTrigger> : ScriptableObject
where TTrigger : ShapeTrigger<THasObject, TTrigger>
where THasObject : IHasObject {
public THasObject data;
}
//RainArea.cs
public class RainArea : ShapeTriggerParent<RainArea.RainTriggerData, RainArea.RainTrigger> {
public class RainTrigger : ShapeTrigger<RainTriggerData, RainTrigger> { }
public class RainTriggerData : IHasObject {
public object obj => null;
}
}
Field 'THasObject ShapeTriggerParent`2::data' from 'PATH_TO_PROJECT\Poroject_ShapeTriggerParent2020\Library\ScriptAssemblies\Assembly-CSharp.dll', exception Failed to resolve THasObject
UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&)
and
Field 'THasObject ShapeTriggerParent`2::data' from 'PATH_TO_PROJECT\Poroject_ShapeTriggerParent2020\Library\PlayerScriptAssemblies\Assembly-CSharp.dll', exception Failed to resolve THasObject
UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&)
The build still finishes when building to Windows Intel 64-bit. I haven’t actually looked into what happens if we try to use any of the code, but I assume trying to grab data from a field that doesn’t resolve would cause bad things.
On at least one console, the build doesn’t complete, though we get the same error (and some others, but we’re investigating this first).
I just upgraded my Unity version today and I’m having a similar compilation issue. When compiling with IL2cpp I get this error:
Field 'T TerrainGeneration.TerrainDetail`1::generationOptions' from '...\Library\ScriptAssemblies\Assembly-CSharp.dll', exception Failed to resolve GenerationOptionType
The type its complaining about is defined like this:
public abstract class TerrainGenerationEngine<GenerationOptionType> : TerrainGenerationEngine
where GenerationOptionType : IGeneratorOptions
{
...
}
IGeneratorOptions is an interface.
TerrainGenerationEngine (with no generic parameter) is abstract and extends MonoBehaviour.
Going to try to downgrade for now. If you need more info let me know
I’m seeing the same thing with the UIWidgets package (version 1.14.2) from the store. We just upgraded to 2021.3.0.2f1 and now we get :
Field ‘TPoint UIWidgets.TracksViewBase`2::valueAtCenter’ from ‘D:\Perforce\StoryEngine_Rick\StoryEngine\Library\ScriptAssemblies\ThirdParty.Runtime.dll’, exception Failed to resolve TPoint
(a half dozen times) on code that used to compile fine. I’ve tried rebuilding assets, deleting my library and rebuilding, etc. and it doesn’t help.
I’m facing the same problem on Unity 2021.3.1f1 and 2021.3.2f1, the build process is failing when I try to build for Android. When I build the project on Unity 2021.2.17f1 this problem don’t occurs.
@JoshPeterson This issue (or a really similar one) also happens without IL2CPP. All that is needed for us is a specific set of generics usage while building for win64. Our case number is 1426750. For us this happened while trying to upgrade from 21.2.13f1 to 21.3.2f1
It looks like our QA team has processed the bug report, and it is assigned to a development team to correct. I don’t know about a workaround, unfortunately, but I have mentioned this forum thread to the development team, so they will likely follow up with details.
It’d be great to get those details. Mostly wondering if the bug is likely to be an easy fix, or if we should rewrite a bunch of our code to be less generic.
A development team is investigating the bug report now, but I’m not sure of the status of the investigation. I’ll as them to respond here with details when they have some.
It’s something we need to fix, for sure. I will be investigating/fixing this as I might have regressed some behaviour with what @billykater posted above
