Proposal: Get rid of "checked" build flavor

[jkotas]

checked build flavor is a foreign concept that takes a lot of explaining and causes unnecessary complexity.

The checked build flavor (ie build with asserts and optimizations on) is left-over from razzle (the original Windows OS build environment). I believe most project still on razzle (including Windows OS) got rid of it and have just debug (that is built with optimizations on by default) and release.

If developers want to compile the code with C/C++ optimizations off to get better debugging experience, they can pass an extra argument to the build script to turn off the optimizations. It is conceptually no different from e.g. a build script switch to use a different C/C++ compiler for the build.

Should we adopt this for CoreCLR build?

[stephentoub]

If I'm understanding correctly, this isn't exactly removing checked; rather it's getting rid of debug and renaming checked to debug, is that right?

[jkotas]

Yes, that's right.

[stephentoub]

Sounds good to me, but I also almost never build coreclr as debug, only checked and release.

[janvorli]

I always use debug build and use checked only in cases where I need to get slightly better perf, like when running coreclr tests suite. On Linux, debugging coreclr with any optimizations is pretty painful. While on Windows you can easily debug even release build, on Linux you get virtually no locals, no parameter values etc. Even checked is quite bad on Linux.
So if we made debug == checked, I would need to have a command line option in the build scripts that would allow me to disable optimizations. But I agree that separate checked / debug flavors are probably not necessary from all the other points of view.

[jkotas]

Yes, a command line option to turn off optimizations for C/C++ would be part of the plan.

[ViktorHofer]

If we do this we should also clean-up the checked conditions in System.Private.CoreLib in mono:

runtime/src/mono/netcore/System.Private.CoreLib/System.Private.CoreLib.csproj

Lines 90 to 92 in 1a1a541

	<PropertyGroup Condition="'$(Configuration)' == 'Debug' or '$(Configuration)' == 'Checked'">
	<Optimize Condition="'$(Optimize)' == '' and '$(Configuration)' == 'Debug'">false</Optimize>
	<Optimize Condition="'$(Optimize)' == '' and '$(Configuration)' == 'Checked'">true</Optimize>

I assume that we align configurations so that they are doing the same thing on Mono and CoreClr.

[jkoritzinsky]

I’m with @janvorli on this; I always use Debug. I only use checked when reproing test failures so I match what CI is doing. As long as there’s an option to disable optimizations in debug, I’ll be satisfied.

[BruceForstall]

What is the advantage of removing checked? If you want unoptimized binaries with the best debugging experience, you'll need to use a new option, which might confuse your builds. E.g., it might be more confusing in your artifacts directory to know what is optimized and what is not.

I run Debug when debugging, but Checked when running tests. With the new proposal, I would need to go back-and-forth, rebuilding with and without the new flag into the same artifacts location (presumably) to be able to do this. That seems very wasteful.

[BruceForstall]

@dotnet/jit-contrib