Bug Unity will fail to recognize script as MonoBehaviour under specific circumstances

Just got this today with 2020.1.0a7

With a specifically crafted method, Unity will no longer be able to recognize a script as a MonoBehaviour.
I was bitten by this issue because I have a large number of classes that have methods with this exact structure.

A class with a method like this will break it:

Code (CSharp):

1.  
2. namespace SomeAssembly {
3.     using UnityEngine;
4.     public sealed class MonoBehaviourThatBreaksTheParser: MonoBehaviour {
5. #if UNITY_EDITOR
6.         public void SomeMethod() {
7.             //THIS LINE BREAKS THE PARSER WHEN WE ARE INSIDE #if UNITY_EDITOR BLOCKS
8.             Utils.HelperMethod(() => $"{Utils.SomeMethodThatReturnsString()}");
9.             //this line does the same as the above, but the parser will not break
10.             //Utils.HelperMethod(() => string.Format("Some String: {0}", Utils.SomeMethodThatReturnsString()));
11.         }
12. #endif
13.     }
14. }
15.  

Those Util methods are just this

Code (CSharp):

1. namespace SomeAssembly {
2.     using System;
3.  
4.     public static class Utils {
5.  
6.         public static string SomeMethodThatReturnsString() {
7.             return "AA";
8.         }
9.  
10.  
11.         public static void HelperMethod(Func<string> s) { }
12.  
13.     }
14. }
15.  

Any of the following changes makes the issue no longer trigger (it's very specific)

* Replacing Utils.SomeMethodThatReturnsString() with anything that is not a parameterless method (that returns anything)
* removing the #if UNITY_EDITOR block
* using string.format instead of string concatenation ($)


Anyone else got this? I just submitted a report (case #1189349) with a micro-project that reproduces the issue.

A bit of extra info: It does not reproduce on a5

 

Does it output any error message?

 

None.
I had a few other parser issues before and it's always silent.
Nothing anywhere.

I even bind to the actual console writer to see if there's any internal messages that aren't being output to log files, but it's completely silent.

I had one longstanding with a specific #if usage that was because of a single space after a curly brace.
It took so long for it to be solved that I just added a rule to my code analysis to break my formatting for that specific case.
This one would be a bit more annoying to do that because of how involved it is.

 

Isn't unity using the Roslyn c# compiler nowadays?

 

Still present in a8 today. I guess it didn't make the cut for a8.

 

I'm still seeing this in a9, but under a slightly different scenario. Still related to interpolated strings, though.
Should I submit a new bug report or update the current one?


The valid MonoBehaviour below breaks the parser.
Removing the division (/) makes it work again.
Removing the #if also makes it work again.
Using string.Format instead of interpolation as well.

Code (CSharp):

1.  
2. namespace SomeAssembly {
3.     using UnityEngine;
4.     public sealed class MonoBehaviourThatBreaksTheParser: MonoBehaviour {
5. #if UNITY_EDITOR
6.         public void SomeMethod() {
7.             this.SomeMethod($"TOOK {100f / 1000f}s");
8.         }
9.         public void SomeMethod(
10.             string message) {
11.             //nothing
12.         }
13. #endif
14.     }
15. }
16.  
17.  

 

QA instructed me to create a new bug report for this one.
Case is #1193024