Specifying generic constraints of compile-time introduced type

I have a TypeAspect that has three attribute arguments when applied to a type. One of these is a

Type

Type

and is sprinkled liberally through my resulting compiled target. Since generic typed aspects aren't yet supported (https://github.com/postsharp/Metalama/issues/199) and one cannot limit eligibility based on instance members (such as this Type - https://github.com/postsharp/Metalama/issues/198), I'm at a loss as to how I can specify the generic constraints of this type (must implement

IEquatable<>

IEquatable<>

IEquatable<>

IEquatable<>) at compile-time otherwise.

Any ideas? Thanks!

GitHub

Feature request: Support generic aspect types (TypeAspect) · Issue ...

I have a need to apply generic constraints to a type passed into an aspect. This is because the type is used in downstream methods which themselves have such constraints. This means that it's n...

GitHub

Issues · postsharp/Metalama

Metalama is a Roslyn-based meta-programming framework. Use this repo to report bugs or ask questions. - Issues · postsharp/Metalama

Petr Onderka•8/1/23, 8:29 AM

I still think that a reporting an error as a diagnostic is currently the best option.
You mention in one of the issues that when your aspect is applied incorrectly, it produces lots of errors. I think that can be avoided using something like:

public override void BuildAspect(IAspectBuilder<INamedType> builder)
{
    bool parameterSatisfiesConstraint = ...;
    if (!parameterSatisfiesConstraint)
    {
        builder.Diagnostics.Report(parameterDoesNotSatisfyConstrainError.WithArguments(...));
        return;
    }

    // actually implement the aspect here
}

public override void BuildAspect(IAspectBuilder<INamedType> builder)
{
    bool parameterSatisfiesConstraint = ...;
    if (!parameterSatisfiesConstraint)
    {
        builder.Diagnostics.Report(parameterDoesNotSatisfyConstrainError.WithArguments(...));
        return;
    }

    // actually implement the aspect here
}

WhitOP•8/1/23, 9:02 AM

Yeah, I've got a whole pile of issues showing up because some of the types I'm instantiating have generic constraints on them and I'm not able to show that the Type I pass into the attribute actually has those constraints - it struck me that I could just use the generic attributes from C#11, but when I tried that I learned that they are not yet supported.

WhitOP•8/1/23, 9:09 AM

Since generic attributes are on the distant roadmap, let me ask this another way. Metalama is generating valid-looking C# except that the compiler simply doesn't see that the type as used implements those constraints, so it doesn't like the lines Metalama generates that pass this type via a TypeFactory into a new expression as a generic parameter.

Do you have any suggestions of how I might indicate that a given Type actually implements IEquatable<>, IComparable and IComparable<> to downstream places where I pass it in via a TypeFactory such that the compiler would be able to understand it implemented these interfaces even though they're not generically constrained on the attribute?

Petr Onderka•8/1/23, 9:32 AM

The generated code isn't special, whatever works in regular C# should work in generated code as well.
Can you give an example of generated code that doesn't work for you?

WhitOP•8/1/23, 9:52 AM

Yeah, I'll see if I can't narrow this down to something that's not too.. long

WhitOP•8/1/23, 10:07 AM

I may have to sleep on this, but I'll try to get a sample that's not too long that demonstrates the issue - it's a trick since this whole thing is one long set of INamedTypes and IFields/Properties from the start to the end

Petr Onderka•8/1/23, 10:14 AM

Thanks.
(Though keep in mind that length is not the most important factor, being self-contained is. If you could easily produce long code that I can use to reproduce the issue, that's still mostly fine. Having short repro is always appreciated, but not strictly speaking necessary.)

WhitOP•8/1/23, 10:16 AM

Yeah, that's the trick too - I'm trying to do an awful lot of things at once with this aspect and while it generates code at this point, I started the day with 36 runtime errors and have since narrowed it down to 16. Something happened with the method that was showing all those constraint errors earlier and now it's not populating anything at all, but I've been tackling the other bugs trying to circle back to it for this issue.

public override void BuildAspect(IAspectBuilder<INamedType> builder) { bool parameterSatisfiesConstraint = ...; if (!parameterSatisfiesConstraint) { builder.Diagnostics.Report(parameterDoesNotSatisfyConstrainError.WithArguments(...)); return; } // actually implement the aspect here }