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

[JosieBigler]

I'd be interested in making the above changes @Jehoel outlined. In terms of testing, would that be a new Assertion in the current Theory or a new Theory?

[buyaa-n]

Thanks @JosieBigler, assigning to you. If it is covered well with current tests then no need to add new tests, just need to fix the current test behavior, could not say for sure as I did not check the existing tests. you would see test coverage after fixing the issue and running the tests