C# Compiler Request for 5.4 build

Please release a test build for the 5.4 branch if possible.
There are developers who already switched to 5.4 and therefore cannot try the 5.3 test build

Thanks

 

Sign me up.

 

same here !

 

I'd certainly be interested as well.

 

With all the features and stabilisation added to 5.4, this would help greatly to keeping it current

 

I don't have a project currently, but I suspect most who are trying to use the new features and planning to ship in 5.4 timelines will want to bear the pain of upgrade now while they are in 5.4 beta (or shortly after) rather than ship and then wait.
Certainly for consoles, you want to irk out as much as possible.

 

I myself would really like to try the (un)supported compiler in 5.4 when that is publicly released (I guess this release is really close considering the roadmap?)

I've got no idea how hard this will be to implement, but would it be possible to add the new compiler to the unity build where we can choose in a dropdown menu in the settings which compiler to use, in the same way that we can currently choose between the mono/IL2CPP runtime for some platforms? Again, I have no idea how hard this is to implement or how easy it is to switch the compilers used live, but this is just a wild idea I got. If it is feasable, you could mark it as experimental during the 5.4 cycle, like you guys are doing for other features currently and have done for the IL2CPP rollout. This approach would be preferable over a whole seperate build of unity since it is easier to switch back to the old compiler might we encounter a specific problem

As for the rest, I personally wouldn't mind if you guys skipped a supported compiler for the 5.3 version, assuming that the 5.4 build will be at least as stable as 5.3 and considering how close the 5.4 release is. If I want to be on the bleeding edge of Unity's development, I will probably upgrade to 5.4 anyway.

 

Thanks for your explanation, you mention some good points that I had not considered yet and I understand your reasoning. It is nice to hear that you guys have at least considered the option.

While a little bit off topic, does this mean that there will be an experimental option provided in a similar way in the feature, when the new language features and/or the new GC are being rolled out?

 

I see. As long as the custom builds are periodically updated to new minor releases, that should be completely fine. I like the direction that you guys are taking for the experimental features, so thumbs up for that!

 

I've been using 5.4 for a few months now for a sequel I'm developing.

Would be happy to test the new C# compiler for 5.4 if available.

Happy to wait 'til 5.5 too.

 

Hey, Josh and everyone else in this thread!

I'm really glad to see all these changes towards compiler upgrade, we all waited for this for so long!
Thanks for letting us try it before official release!
I'm already using 5.3.5p8 with new compiler to test my assets and tried it for one huge project - but unfortunately that huge project won't compile because in new compiler some bugs were fixed which we are exploiting haha =D
E.g. DllImport for generic methods:

Code (CSharp):

1.             [DllImport(c_CrtDll, EntryPoint = c_Memcpy, CallingConvention = c_CallingConvention)]
2.             static extern IntPtr memcpy(ref T dest, byte [] src, UIntPtr count);

Though we'll fix it in future and will try new compiler for our huge project once again.

Anyways, it would be really awesome to be able to test new compiler on 5.4 branch.

 

Yeah, old compiler eats this and it works %)
Thanks for picking this one up to your list of known breaking changes ^^

Fun fact: when I run debug via VSTU it fails to compile it at VS, but still allows to run "last successful build" and debugging works fine.

 

Add it on 5.4 and I'll try it out. I won't be switching any project back down to 5.3 just to try a new compiler. That's if 5.5builds with it are not going to be out for a while then even more reason.

 

My preference (if possible) is to simply add it as a new "preview" drop down option for the compiler to use in 5.4.
Then let people use / not use it as they so wish, with the added benefit of not having to run / install multiple versions on machines (especially where disk space is a premium).

This was done with WebGL to great effect for a fair few builds.

So if it's possible to have it as an Option in the main build, that would be Nirvana

 

I suggested this a few post above but the one of the Unity employees mentioned some problems with that. The reasons I like the idea however seem to be the same as yours

 

+1 for a 5.4 version of the new compiler. We have a quite big and nearly finished project to test with.

 

Agreed 5.4 version would be awesome/

 

Hey @JoshPeterson - I would also like to add our voice for having an option to use the new compiler with v5.4.

I also wanted to let you know that we shipped a patch to our 150k+ userbase in War for the Overworld compiled with v5.3.5p8-compiler-upgrade yesterday. Everything looks solid so far.

 

Fully understood.

 

I'm certainly interested in (1). We are currently doing optimization work in our project - including memory allocation optimization. This would make it much simpler by not having to care about replacing each foreach.
At the shipping title we can solve the issue other ways, but during development it would be much easier this way.

As for (2) it would be good for 5.4 depending on when 5.5 comes out. If it will take as long as the 5.4 version then it will be too late for out project.

 

If the 5.4 compiler alpha roughly follows the latest patch release, it'll be pretty much the same as usual for me. It could even lag a week and be released less often, because I wouldn't be updating as frequently as I currently do

 

Hey @JoshPeterson just wondering where the v5.4 updated preview is at? We could really make use of it shortly.

 

Actually I realized soon after that the v5.5 beta patch notes shows that this updated compiler is in there, so we've upgraded to the beta. So all good.

 

I suppose that's both good and bad news at the same time. Glad you guys are working on it though, appreciated!

 

I think delaying for known and fixed bugs is good.

 

So maybe then build 5.4.1 that just came out?

 

I've started to use the new 5.4 compiler build, although I'm experiencing some issues with the Visual Studio Tools for Unity.

While I can step over breakpoints fine, I seem to be unable to view any values. Both the 'Local' and 'Auto' tabs are also blank.

This seems like strange behaviour since I can't see how an updated compiler would affect the runtime debug information, unless it's just not generating the symbol files properly.

I'll see if I can do anything to consistently replicate it but otherwise feel free to treat this is a one-off artifact.

 

Don't know if you have already seen this, but have a look at the changes this guy made to make roslyin compatible with visual studio, maybe some are in common.
https://github.com/SaladLab/Unity3D...r/core/RoslynCompilerFix/CSharpCompilerFix.cs
https://github.com/SaladLab/Unity3D.IncrementalCompiler/blob/master/docs/UnderTheHood.md

Anyway, for me so far the new mono 4.4 compiler seem to work well.

 

Decided to give this a go with the RNG library I've been working on. I've tuned the library fairly aggressively for performance, so I have a convenient measurement system I can use to carefully observe speed.

For the most part, I didn't see any substantial difference between the two compilers, nor did I expect any (aside from a wee bit of optimistic hope for small speed increases). Things continued to function precisely as they had. Certainly no crashes or other bugs* that I noticed, and all my unit tests continued to pass.

The one thing that stood out was that my functions for generating random floats experience around 25% loss of performance on the new compiler compared to the official Unity 5.4 compiler. My float functions were already slightly slower than the nearly identical functions dealing with doubles, but I had let that slide previously; figured it was just due to operating on 32-bit data on a 64-bit processor. But the new compiler seems to dislike floats compared to doubles even more strongly, which is a tad worrisome given how heavily Unity makes use of floats instead of doubles.

All the same, these are artificially tight and isolated loops that I'm measuring, and I'm doing some StructLayout/union trickery that's bound to make the compiler work harder, so perhaps a lot of it will just disappear in the pipelining and general noisiness of more complex code paths.

*One final note, the compiler did trip up on code flow analysis in the presence of gotos. I consider it more of a Mono issue than a Unity responsibility anyway, and I worked around it with some code rearrangement, but for the sake of sharing, the following simplified code causes the new compiler to complain that "error CS0177: The out parameter `x' must be assigned to before control leaves the current method", while the current compiler accepts the code without error.

Code (CSharp):

1. static void Test(bool cond, out int x)
2. {
3.     if (cond)
4.         goto Label;
5.     Label:
6.     x = 0;
7. }

 

Done (via private conversation) and done (Case 834753)!