The resolver does not validate constraints when constructing a generic type #95

New issue

Open

opened 2012-08-14 09:51:23 -05:00 by erik-kallen · 4 comments

erik-kallen commented

2012-08-14 09:51:23 -05:00

(Migrated from github.com)

Failing test:

        [Test]
        public void CannotConstructGenericTypeWithTypeArgumentThatDoesNotSatisfyConstraint() {
            string program = @"
public class X<T> where T : class {}
public class C {
    void M() {
        $new X<int>()$;
    }
}";

            var rr = Resolve<CSharpInvocationResolveResult>(program);
            Assert.IsTrue(rr.IsError);
        }

Failing test: ``` [Test] public void CannotConstructGenericTypeWithTypeArgumentThatDoesNotSatisfyConstraint() { string program = @" public class X<T> where T : class {} public class C { void M() { $new X<int>()$; } }"; var rr = Resolve<CSharpInvocationResolveResult>(program); Assert.IsTrue(rr.IsError); } ```

dgrunwald commented

2012-09-07 10:19:56 -05:00

(Migrated from github.com)

I'm not sure if the resolver should attempt to discover this type of error - this might make more sense in an issue provider.

You can use the static OverloadResolution.ValidateConstraints method to test the constraints yourself.

    static bool ValidateConstraints(ParameterizedType pt)
    {
        var typeParameters = pt.GetDefinition().TypeParameters;
        var substitution = pt.GetSubstitution();
        for (int i = 0; i < pt.TypeParameterCount; i++) {
            if (!OverloadResolution.ValidateConstraints(typeParameters[i], pt.GetTypeArgument(i), substitution))
                return false;
        }
        return true;
    }

I'm not sure if the resolver should attempt to discover this type of error - this might make more sense in an issue provider. You can use the static `OverloadResolution.ValidateConstraints` method to test the constraints yourself. ``` static bool ValidateConstraints(ParameterizedType pt) { var typeParameters = pt.GetDefinition().TypeParameters; var substitution = pt.GetSubstitution(); for (int i = 0; i < pt.TypeParameterCount; i++) { if (!OverloadResolution.ValidateConstraints(typeParameters[i], pt.GetTypeArgument(i), substitution)) return false; } return true; } ```

erik-kallen commented

2012-09-07 10:21:43 -05:00

(Migrated from github.com)

Actually, I do not care. I just reported the issue because the resolver does validate constraints on method invocation, making me think it is inconsistent to not do it when invoking a constructor.

dgrunwald commented

2012-09-07 10:23:27 -05:00

(Migrated from github.com)

But the constructor invocation isn't really the right place to report this error - it would be better reported directly on the AstType within the constructor invocation.

But the constructor invocation isn't really the right place to report this error - it would be better reported directly on the `AstType` within the constructor invocation.

erik-kallen commented

2012-09-07 10:27:14 -05:00

(Migrated from github.com)

Wouldn't a good model in that case be that the AstType resolves to a TypeResolveResult with an error?

This discussion has been locked. Commenting is limited to contributors.

No labels

Bug

Feature Request

NR6Pack

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-icsharpcode/NRefactory#95

No description provided.

Rows
Columns