Fix TUnit0001 not reporting for TypedDataSourceAttribute and other IDataSourceAttribute implementations

[Copilot]

TUnit0001 (argument/parameter mismatch) was not firing for TypedDataSourceAttribute<T> / ITypedDataSourceAttribute<T> and other custom IDataSourceAttribute implementations, allowing mismatched test signatures to compile silently and fail only at runtime.

// This should produce TUnit0001 but compiled without error
[Test]
[CustomData] // provides string
public void Test(string asdf, int notExistingParameter) { }

public class CustomData : TypedDataSourceAttribute<string> { ... }

Three bugs in TestDataAnalyzer.cs:

• Filter missed indirect interface implementations — used currentType.Interfaces (direct only) instead of AllInterfaces, so types implementing IDataSourceAttribute transitively through ITypedDataSourceAttribute<T> were invisible to the analyzer
• Dispatch never routed to CheckDataGenerator — only checked for specific base classes (DataSourceGeneratorAttribute/AsyncDataSourceGeneratorAttribute) by name; replaced with a generic IDataSourceAttribute interface check that works for all data source implementations, including custom user-created ones. Added continue statements to prevent double-dispatching for attributes already handled by specific handlers (Arguments, MethodDataSource).
• Open generic comparison always failed — compared ConstructedFrom.GloballyQualified() (returns ITypedDataSourceAttribute<T>) against backtick-arity format (ITypedDataSourceAttribute`1); fixed to use GloballyQualifiedNonGeneric() which strips type parameters for a correct match. This also fixes the same broken comparison that already existed in CheckDataGenerator but was unreachable due to the dispatch bug.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Bug]: TUnit0001 not reporting for TypedDataSourceAttribute</issue_title>
<issue_description>### Description

I assumed that TUnit0001 would work with ITypedDataSource, and thus TypedDataSourceAttribute. However, the following, obviously wrong example, compiles just fine:

public class Playground
{
    [Test]
    [CustomData]
    public void Test(string asdf, int notExistingParameter)
    {
        Assert.Fail("foobar");
    }
}

[AttributeUsage(AttributeTargets.Method)]
public class CustomData : TypedDataSourceAttribute<string>
{
    public override async IAsyncEnumerable<Func<Task<string>>> GetTypedDataRowsAsync(
        DataGeneratorMetadata dataGeneratorMetadata
    )
    {
        await Task.Yield();
        yield return () => Task.FromResult("one");
    }
}

Expected Behavior

I expected that it would not compile and show an error, since the typed data source does not method the test method signature.

Actual Behavior

I expected that the TUnit0001 error is shown, as it is shown for a mismatching [Arguments] for example.

Steps to Reproduce

See the code above.

TUnit Version

1.13.11

.NET Version

.NET 10

Operating System

macOS

IDE / Test Runner

JetBrains Rider

Error Output / Stack Trace

Running it with `dotnet test`, the following error is shown:

TUnit.Engine.Exceptions.TestFailedException: ArgumentException: Expected exactly 2 arguments, but got 1

Additional Context

No response

IDE-Specific Issue?

• I've confirmed this issue occurs when running via dotnet test or dotnet run, not just in my IDE</issue_description>

<agent_instructions>The analyzer should work off of the most nested base/interface that supplies the type information. Don't create special cases for subtypes, work off of the super/base/interface types</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes [Bug]: TUnit0001 not reporting for TypedDataSourceAttribute #4740

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[thomhurst]

@copilot We shouldn'thave to check if it's a ITypedDataSourceAttribute - Because that should inherently be an IDataSourceAttribute. We need to design this in a way that it is generic and works across all data types - Including custom ones creates by users

[Copilot]

@copilot We shouldn'thave to check if it's a ITypedDataSourceAttribute - Because that should inherently be an IDataSourceAttribute. We need to design this in a way that it is generic and works acr...

Refactored in 42e4de5. The dispatch now uses IDataSourceAttribute (the root interface) to route all data source attributes to CheckDataGenerator(), with continue statements to skip attributes already handled by specific handlers (Arguments, MethodDataSource). Removed all special-casing for ITypedDataSourceAttribute, DataSourceGeneratorAttribute, AsyncDataSourceGeneratorAttribute, and ClassDataSourceAttribute from the dispatch logic.

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

This PR correctly fixes three related bugs in the analyzer:

1. Interface detection - Changed from Interfaces to AllInterfaces to catch indirect IDataSourceAttribute implementations
2. Dispatch routing - Replaced fragile string-based checks with a clean IDataSourceAttribute interface check, plus added continue statements to prevent double-dispatching
3. Generic comparison - Fixed the broken GloballyQualified() + backtick-1 comparison with GloballyQualifiedNonGeneric()

The logic changes are sound and the tests properly validate the fixes.