Another Internal Compiler Error

I am using Unity 4 on a Mac.

I am getting an Internal Compiler Error. I did a search here and there are a lot of them. I tried to further refine my search to include my particular error and didn’t get any smaller result set even though when I look at many of the other posts about this I don’t see my stack trace as the same as the others. Therefore I am posting here. Sorry if this has already been answered as I couldn’t find it.

I am trying to port some business logic code from a desktop C# application. I have slowly brought over the single classes one at a time, but can’t pin down exactly when the internal compiler error triggered because I had brought over several classes and was fixing missing things in them until they were all fixed and then the internal compiler error showed up.

Mainly I want to know how do I figure this out? The stack trace doesn’t help me any because I have no idea which of my source files it is working on when the error occurs. What do I do?

Stack Trace:

Internal compiler error. See the console log for more information. output was:Stacktrace:

at (wrapper managed-to-native) System.Type.MakeGenericType (System.Type,System.Type) <0x00004>
at (wrapper managed-to-native) System.Type.MakeGenericType (System.Type,System.Type) <0x00004>
at System.Type.MakeGenericType (System.Type) <0x00144>
at Mono.CSharp.GenericTypeExpr.DoResolveAsTypeStep (Mono.CSharp.IMemberContext) <0x0009c>
at Mono.CSharp.TypeExpr.ResolveAsTypeStep (Mono.CSharp.IMemberContext,bool) <0x0001e>
at Mono.CSharp.Expression.ResolveAsBaseTerminal (Mono.CSharp.IMemberContext,bool) <0x0004d>
at Mono.CSharp.Expression.ResolveAsTypeTerminal (Mono.CSharp.IMemberContext,bool) <0x0001b>
at Mono.CSharp.Nullable.NullableType.DoResolveAsTypeStep (Mono.CSharp.IMemberContext) <0x000f6>
at Mono.CSharp.TypeExpr.ResolveAsTypeStep (Mono.CSharp.IMemberContext,bool) <0x0001e>
at Mono.CSharp.Expression.ResolveAsBaseTerminal (Mono.CSharp.IMemberContext,bool) <0x0004d>
at Mono.CSharp.Nullable.NullableType.ResolveAsTypeTerminal (Mono.CSharp.IMemberContext,bool) <0x00018>
at Mono.CSharp.Nullable.LiftedBinaryOperator.LiftResult (Mono.CSharp.ResolveContext,Mono.CSharp.Expression) <0x000a8>
at Mono.CSharp.Nullable.LiftedBinaryOperator.ResolveUserOperator (Mono.CSharp.ResolveContext,System.Type,System.Type) <0x00039>
at Mono.CSharp.Binary.ResolveOperator (Mono.CSharp.ResolveContext) <0x001a4>
at Mono.CSharp.Binary.DoResolveCore (Mono.CSharp.ResolveContext,Mono.CSharp.Expression,Mono.CSharp.Expression) <0x00016>
at Mono.CSharp.Nullable.LiftedBinaryOperator.DoResolve (Mono.CSharp.ResolveContext) <0x0014d>
at Mono.CSharp.Expression.Resolve (Mono.CSharp.ResolveContext,Mono.CSharp.ResolveFlags) <0x0015b>
at Mono.CSharp.Expression.Resolve (Mono.CSharp.ResolveContext) <0x00015>
at Mono.CSharp.Binary.DoResolve (Mono.CSharp.ResolveContext) <0x008e0>
at Mono.CSharp.Expression.Resolve (Mono.CSharp.ResolveContext,Mono.CSharp.ResolveFlags) <0x0015b>
at Mono.CSharp.Expression.Resolve (Mono.CSharp.ResolveContext) <0x00015>
at Mono.CSharp.Expression.ResolveBoolean (Mono.CSharp.ResolveContext,Mono.CSharp.Expression,Mono.CSharp.Location) <0x0001a>
at Mono.CSharp.If.Resolve (Mono.CSharp.BlockContext) <0x0002a>
at Mono.CSharp.Block.Resolve (Mono.CSharp.BlockContext) <0x0044e>
at Mono.CSharp.Block.Resolve (Mono.CSharp.BlockContext) <0x0044e>
at Mono.CSharp.ToplevelBlock.Resolve (Mono.CSharp.FlowBranching,Mono.CSharp.BlockContext,Mono.CSharp.ParametersCompiled,Mono.CSharp.IMethodData) <0x0008d>
at Mono.CSharp.MethodData.Emit (Mono.CSharp.DeclSpace) <0x001ff>
at Mono.CSharp.AbstractPropertyEventMethod.Emit (Mono.CSharp.DeclSpace) <0x00039>
at Mono.CSharp.PropertyBase.Emit () <0x0007b>
at Mono.CSharp.Property.Emit () <0x000b1>
at Mono.CSharp.TypeContainer.EmitType () <0x00353>
at Mono.CSharp.RootContext.EmitCode () <0x000aa>
at Mono.CSharp.Driver.Compile () <0x00782>
at Mono.CSharp.Driver.Main (string) <0x0008f>
at (wrapper runtime-invoke) .runtime_invoke_int_object (object,intptr,intptr,intptr) <0x00043>

I’ve been having internal compiler errors in my project also, and there are a couple things I’ve found that could help.

First, there is a technique which works well for narrowing-down where the internal compiler error happens.

First the thought process:

A) I noticed that compiler errors showing up in Visual Studio, when I attempted to build the project there (which failed because Unity hadn’t built the DLL file, btw), were not showing up in the Unity console/error log.

B) This made me realize that the internal compiler error must be happening at some specific line in some specific file, and that once it hit that line, it stopped compiling the rest of the files. (and thus it never noticed the normal code issues (e.g. “int i = 0 / 0;”) that Visual Studio picked up)

C) I looked into the Unity Editor logs, and noticed that the files were all being sent to the compiler in alphabetical order–in other words, in basically the same order you see them in the Project view. (the one difference being how they handle capital letters–Unity and Visual Studio consider ‘a’ to be before ‘B’, whereas the compiler considers ‘a’ to be after ‘B’, since ‘B’ is capitalized, and it always puts capitalized letters first (presumably because capitalized letters come first in the character map))

D) I realized that I could find which file the ‘internal compiler error’ happened in by intentionally creating normal compile errors at the bottom of each file, in turn, until I saw the normal error not show up in the Console. (indicating that it came after the internal-compiler-error-causing line)

So now:

Tip #1) The technique.

If you get an ‘internal compiler error’:

  1. Place the following code at the very bottom of the first (alphabetically speaking) script file: (in other words, the top-most script file in the Project view)

    class CompileBreaker { int i = 0 / 0; }

  2. If you still get the ‘internal compiler error’, then the issue is somewhere in the file. (you can try placing the CompileBreaker at the top, just to make sure) If not, then remove the CompileBreaker code from the file, and add it to the bottom of the next file.

  3. Repeating steps 1 and 2 for each script file, in alphabetical order.

The first time I used this technique, (which was just a few minutes ago), I was pretty lucky. I found the cause of my ‘internal compiler error’ in the second file, “Core.cs”. Which brings me to my next point, which is that…

Tip #2) The Mono compiler for Unity apparently has an issue with partial classes.

Here is the file I found to have caused the internal compiler error, with the error-causing line marked:

using System;

namespace ManagedLzma.LZMA.Master
{
    public static partial class LZMA // <<< the line that caused the 'internal compiler error'
    {
        [System.Diagnostics.Conditional("SHOW_DEBUG_INFO")]
        internal static void DebugPrint(string format, params object[] args)
        {
            System.Diagnostics.Debug.WriteLine(String.Format(format, args));
        }

        internal static void Print(string format, params object[] args)
        {
            System.Diagnostics.Debug.WriteLine(String.Format(format, args));
        }
    }
}

class CompileBreaker { int i = 0 / 0; } // my CompileBreaker code that wasn't reached

I removed the word “partial” from the line, and changed the class name to “LZMA_RenamedForNow”, and the compiler successfully reached the CompileBreaker code at the bottom. I then moved the CompileBreaker code to the next file, found the same issue (with it having “partial” class declarations), and fixed it. Moved the CompileBreaker to the next file. And so on.

Each time the CompileBreaker code is reached, you know the code up to that point is fine, so you just move it to the bottom of the next file.

It’s worked really well for helping me solve this sort of problem, that is otherwise almost pure guesswork. (before this I was trying to delete and comment out files and code blocks, but that became very difficult because the library with the issues has dozens of classes which are interlinked with each other–causing early, normal compile errors, that blocked my ability to see where the ‘internal compiler error’ was lying (since the ‘internal compiler error’ is only seen if it doesn’t encounter normal errors first))

Anyway, hope this helps anyone still having issues with finding where their project’s ‘internal compiler errors’ lie.

EDITED:

From everything I can tell these Internal Compiler errors happen when I try to include a .dll file that requires .NET functionality that is higher than 2.0 and part of the bleeding edge stuff included in Unity’s mono. That is probably why it is called bleeding edge, eh?

Anyway, the answer is just trial and error. Some newer .NET stuff works and some just doesn’t even though it is included and supposedly “in there”.
<<<<<

I am having to put this in an answer spot because I can’t format code and such in a comment.

I have discovered the lines of code that are causing the Internal compiler error. I just don’t know how to solve it.

I have created my own Tuple class because it is not in Unity. It is defined as follows:

using System;

namespace System
{
    // This is a very minimalistic implementation of Tuple'2 that allows us
    // to compile and work on versions of .Net eariler then 4.0.
    public struct Tuple<TItem1, TItem2>
    {
        public Tuple(TItem1 item1, TItem2 item2)
        {
            this = new Tuple<TItem1, TItem2>();
            this.Item1 = item1;
            this.Item2 = item2;
        }

        public TItem1 Item1 { get; private set; }
        public TItem2 Item2 { get; private set; }

        public override bool Equals(object obj)
        {
            if (obj is Tuple<TItem1, TItem2>)
            {
                Tuple<TItem1, TItem2> that = (Tuple<TItem1, TItem2>)obj;
                return object.Equals(this.Item1, that.Item1) && object.Equals(this.Item2, that.Item2);
            }
            else
            {
                return false;
            }
        }

        public override int GetHashCode()
        {
            return ((this.Item1 != null) ? this.Item1.GetHashCode() : 0) ^ ((this.Item2 != null) ? this.Item2.GetHashCode() : 0);
        }

        public static bool operator ==(Tuple<TItem1, TItem2> left, Tuple<TItem1, TItem2> right)
        {
            return left.Equals(right);
        }

        public static bool operator !=(Tuple<TItem1, TItem2> left, Tuple<TItem1, TItem2> right)
        {
            return !left.Equals(right);
        }
    }
	
    // This is a very minimalistic implementation of Tuple'3 that allows us
    // to compile and work on versions of .Net eariler then 4.0.
    public struct Tuple<TItem1, TItem2, TItem3>
    {
        public Tuple(TItem1 item1, TItem2 item2, TItem3 item3)
        {
            this = new Tuple<TItem1, TItem2, TItem3>();
            this.Item1 = item1;
            this.Item2 = item2;
            this.Item3 = item3;
        }

        public TItem1 Item1 { get; private set; }
        public TItem2 Item2 { get; private set; }
        public TItem3 Item3 { get; private set; }

        public override bool Equals(object obj)
        {
            if (obj is Tuple<TItem1, TItem2, TItem3>)
            {
                Tuple<TItem1, TItem2, TItem3> that = (Tuple<TItem1, TItem2, TItem3>)obj;
                return object.Equals(this.Item1, that.Item1) && object.Equals(this.Item2, that.Item2) && object.Equals(this.Item3, that.Item3);
            }
            else
            {
                return false;
            }
        }

        public override int GetHashCode()
        {
            return ((this.Item1 != null) ? this.Item1.GetHashCode() : 0) ^ ((this.Item2 != null) ? this.Item2.GetHashCode() : 0) ^ ((this.Item3 != null) ? this.Item3.GetHashCode() : 0);
        }

        public static bool operator ==(Tuple<TItem1, TItem2, TItem3> left, Tuple<TItem1, TItem2, TItem3> right)
        {
            return left.Equals(right);
        }

        public static bool operator ==(Tuple<TItem1, TItem2, TItem3> left, object right)
        {
            return left.Equals(right);
        }

        public static bool operator !=(Tuple<TItem1, TItem2, TItem3> left, Tuple<TItem1, TItem2, TItem3> right)
        {
            return !left.Equals(right);
        }

        public static bool operator !=(Tuple<TItem1, TItem2, TItem3> left, object right)
        {
            return !left.Equals(right);
        }
    }
}

In the file that is cause the problem I have a List of those Tuples like so:

		private List<Tuple<int, UInt32, byte[]>> Arguments;

Now here are the lines of code that cause the internal compiler error:

				var f = Arguments.FirstOrDefault(a => a.Item3 != null);
				if (f == null)
					throw new NotSupportedException("No chunk in this SerialCommand!");

Specifically it is the if (f == null)

If I change that line to something else the internal compiler error goes away. I am guessing it has something to do with the fact that FirstOrDefault is returning something the compiler is not able to resolve properly.

The big question is what do I do about it?

It sounds like compiler might be confused and “optimising” one of the implementations of a Generic that you “aren’t using” away. Theres a place you can add exceptions to this, to force the compiler to include a Generic implementation your code is using that it can’t find, but I can’t find it right now.

If this is the problem, be glad its crashing the compiler… When we had the problem at work in Unity 3 it was a runtime error… :confused:

What might help you is if you explicitly specify the < T > you are expecting in FirstOrDefault. Ie:

Arguments.FirstOrDefault<Tuple<int, UInt32, byte[]>(a => a.Item3 != null); // I think?

If that doesn’t work, you could try making a proper, “well-defined” delegate instead of a linq expression that the compiler tries to work out the type of.