Under what conditions can `TypeBuilder.CreateType()` return null

[lonix1]

Issue description
Under what conditions can TypeBuilder.CreateType() return null?

Target framework

• .NET Core 5, 6
• .NET Framework
• .NET Standard

Details
The TypeBuilder.CreateType() method is defined as nullable:

public Type? CreateType();

Under what conditions can it return null? The docs do not say.

Please document this method signature.

[daiplusplus]

@lonix1 Under what conditions can TypeBuilder.CreateType() return null?

TL;DR: There is no situation when TypeBuilder.CreateType() will return null when CreateType() is being called by user-code. You can safely add a null-forgiving ! to a CreateType() call-site.

---

The current source is at

runtime/src/coreclr/System.Private.CoreLib/src/System/Reflection/Emit/TypeBuilder.cs

Line 1853 in 1a296c0

private TypeInfo? CreateTypeNoLock()

• A quick browse of the current source shows that TypeBuilder.CreateType() only returns null when the TypeBuilder is the builder for an assembly's hidden <Module> class.
  • The <Module> class is a special type that allows assemblies/modules to have eager-initialized globals.
  • The C# language itself doesn't use <Module>, though other languages do (e.g. C++/CLI).
  • Since C# 9.0, you can now opt-in to adding <Module> members via the [ModuleInitializer] attribute.
  • Of course, if you're using Reflection.Emit then you will have always been able to use ModuleBuilder going back to .NET 1.x in 2001.
• <Module>-building TypeBuilder instances cannot be directly instantiated by user-code as it requires a specific internal TypeBuilder() constructor invocation - instead this ctor is called only when you use the ModuleBuilder type.
• The only situation when TypeBuilder.CreateType() method does indeed return null is inside void ModuleBuilder.CreateGlobalFunctions(), which basically ensures that a class <Module> will be defined in the generated dynamic-assembly.

---

So based on that, I think the design of TypeBuilder's API should be changed in a minimally-breaking way:

• Change the current public Type? TypeBuilder.CreateType() method into private Type? TypeBuilder.CreateTypeImpl().
• Add back public Type TypeBuilder.CreateType() (without the nullable return type) which just calls CreateTypeImpl() directly, maybe adding a debug assertion that CreateTypeImpl did not return null?).
• Add a new method to TypeBuilder: internal void CreateGlobalModuleType() which first checks that this.m_isHiddenGlobalType == true (and if not throws, I suppose) and then calls CreateTypeImpl() with a debug assertion that it did return null.

Alternatively, refactor the CreateType() method more thoroughly?

[lonix1]

Wow @Jehoel that was incredibly in depth - my mind boggles at how you'd know all that, thank you!

EDIT
Oh... I see your profile says you're a "former human", so now it makes sense. You're actually a highly intelligent sentient AI / advanced robot. 😄 👍

[lonix1]

BTW I also have an open issue on SO if you copy-paste that into an answer I'll close that. Thanks once more for your help.

[daiplusplus]

my mind boggles at how you'd know all that, thank you!

Oh... I see your profile says you're a "former human", so now it makes sense. You're actually a highly intelligent sentient AI / advanced robot. 😄 👍

Nah, I'm just on the spectrum

[buyaa-n]

@Jehoel is right, we should separate the public API from internal nullable API and make public API non nullable, moving to runtime repo for that