Generator hintName collision

[czirok]

Summary

In GirCore 0.8.0, the GObject subclass source generator fails when two or more [GObject.Subclass<T>] partial classes have the same class name but are declared in different namespaces.

The generator creates the generated source hintName from the short type name only. Because the namespace is not included, different valid C# types can produce the same generated source name.

Version

GirCore 0.8.0

Error message

Generator 'Generator' failed to generate source. It will not contribute to the output and compilation errors may occur as a result. Exception was of type 'ArgumentException' with message 'The hintName 'View.Subclass.g.cs' of the added source file must be unique within a generator. (Parameter 'hintName')'.

Minimal example

namespace GirCoreSample.Axes.ColorsAndPosition;

[GObject.Subclass<Gtk.Box>]
public partial class View
{
}

namespace GirCoreSample.Bars.DelayedAnimation;

[GObject.Subclass<Gtk.Box>]
public partial class View
{
}

Both classes are valid C# types, because they are declared in different namespaces.

The generator currently produces the same generated source name for both classes:

View.Subclass.g.cs

This causes an AddSource collision, because the hintName value must be unique within a generator.

Cause

The GObject subclass generator uses TypeData.Filename when creating the generated source name:

hintName: $"{subclassData.TypeData.Filename}.Subclass.g.cs"

The TypeData.Filename value is produced by TypeDataHelper.GetFileName(...).

The current filename generation is based on the short type name. This is not enough when two different namespaces contain the same class name.

Fix

TypeDataHelper.GetFileName(...) should generate namespace-aware filenames.

The namespace should become part of the generated Filename value, while the existing nested type name handling and generic parameter count handling should remain part of the filename.

This makes generated source names unique for types such as:

GirCoreSample.Axes.ColorsAndPosition.View
GirCoreSample.Bars.DelayedAnimation.View

Instead of both producing:

View.Subclass.g.cs

they should produce different hintName values.

Affected generator paths

This affects every source generator path that uses TypeData.Filename as part of its generated source hintName.

The two relevant paths are:

src/Integrations/GObject-2.0.Integration/SourceGenerator/Subclass/SubclassCode.cs
src/Integrations/Gtk-4.0.Integration/SourceGenerator/Template/TemplateCode.cs

Tests

The GObject integration tests should include two Widget classes with the same short name declared in different namespaces.

This verifies that the GObject subclass generator no longer fails with CS8785 when identical short type names appear under different namespaces.

The GTK integration tests should include the same situation for the GTK template generator.

This verifies that the GTK template generator also receives unique generated source hintName values in this case.

Expected result

The same class name in different namespaces should receive different generated source hintName values.

There should be no AddSource collision when multiple valid C# types share the same short class name.

[czirok]

I implemented the generator hintName collision fix #1545

Test.zip

The attached Test.zip contains a small test application demonstrating the generator hintName collision scenario and the expected fixed behavior.

The test application covers two main generator paths.

First, it contains three GObject subclass types with the same short class name:

• Test.Hintname1.Widget
• Test.Hintname2.Widget
• Test.Hintname3.Widget

Each Widget class is declared in a different namespace, but all three use the same short type name and the same subclass pattern:

• [GObject.Subclass<Adw.Bin>]
• public partial class Widget

The application instantiates all three concrete widget types:

• Test.Hintname1.Widget.NewWithProperties([])
• Test.Hintname2.Widget.NewWithProperties([])
• Test.Hintname3.Widget.NewWithProperties([])

This verifies that the GObject subclass generator can generate unique source hintName values when identical class names appear in different namespaces.

Second, it contains three GTK template subclasses with the same short class name:

• Test.Hintname1.TemplateDemoBox
• Test.Hintname2.TemplateDemoBox
• Test.Hintname3.TemplateDemoBox

Each TemplateDemoBox class is declared in a different namespace, uses [GObject.Subclass<Gtk.Box>], and has its own template resource:

• Hintname1.TemplateDemoBox.ui
• Hintname2.TemplateDemoBox.ui
• Hintname3.TemplateDemoBox.ui

The application instantiates all three template demo boxes:

• Test.Hintname1.TemplateDemoBox.NewWithProperties([])
• Test.Hintname2.TemplateDemoBox.NewWithProperties([])
• Test.Hintname3.TemplateDemoBox.NewWithProperties([])

This verifies that the GTK template generator also receives unique generated source hintName values for identical short class names declared in different namespaces.

At runtime, Program.cs creates an Adw application window, appends the three Widget instances, and appends the three TemplateDemoBox instances to the same vertical Gtk.Box.

The important point is that all duplicated short class names are valid C# types because they are separated by namespace. The generated source filenames must therefore include enough namespace information to avoid AddSource collisions.