Internal compiler error

I was getting this GameObject.active is obsolete as an error all of a sudden one day when I'd always just got them as warnings. As the error stopped my whole project from compiling I tracked the culprit down to a new piece of code:

 try {
 ..... code ...
 } catch (Exception e) }
    Debug.Log("Error");
 }

The reason was because I wasn't actually using the variable e for Exception. Once I removed this the obsolete error disappeared.

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 { public CompileBreaker() { var 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.

---