6

When I pass a string array to a test function like this:

[TestCase( new string[] { "1", "2", "3" }, 1 )]
[TestCase( new string[] { "54", "508" }, 1 )]
[TestCase( new string[] { "768" }, 2 )]
public void someTest( string[] someStrings, int someNumber ) {
    //...
}

The compilation works fine.

But, if I remove integer parameter like the follwoing code snippet shows:

[TestCase( new string[] { "1", "2", "3" } )]
[TestCase( new string[] { "54", "508" } )]
[TestCase( new string[] { "768" } )]
public void someTest( string[] someStrings ) {
    //...
}

A compiler error with the message An attribute argument must be a constant expression, typeof expression or array creation expression of an attribute parameter type occurs.

I basically get the cause of the error, that an array is not a constant type. But why is the compiler accepting an array, if there is another paramter passed to the test function? It even works, if I put another array inside the TestCase:

[TestCase( new string[] { "1", "2", "3" }, new int[] { 1, 2, 3 } )]
[TestCase( new string[] { "54", "508" }, new int[] { 54, 508 } )]
[TestCase( new string[] { "768" }, new int[] { 768 } )]
public void someTest( string[] someStrings, int[] someNumbers ) {
    //...
}
Blackbriar
  • 477
  • 4
  • 14

2 Answers2

3

Let's simplify this to something where overloading isn't involved, and also remove params:

using System;

[AttributeUsage(AttributeTargets.All)]
class FooAttribute : Attribute
{
    public FooAttribute(object[] args)
    {
    }
}

// Error
[Foo(new string[] { "a", "b" })]
class FooTest1 {}

// Error
[Foo(new[] { "a", "b" })]
class FooTest2 {}

// Error
[Foo(args: new string[] { "a", "b" })]
class FooTest3 {}

// Error
[Foo((object[]) new string[] { "a", "b" })]
class FooTest4 {}

// Works
[Foo(new object[] { "a", "b" })]
class FooTest5 {}

// Works
[Foo(new[] { (object) "a", "b" })]
class FooTest6 {}

Basically the compiler is unwilling to supply a string[] for a object[] parameter in an attribute, even though that would normally be fine.

I believe this is a compiler bug, having checked the spec - but I wouldn't like to say for certain. The expression new string[] { "a", "b" } does count as an attribute-argument-expression in spec terms - and if you change the parameter type to string[] it works fine. So it's the application of that argument type to the parameter that's the problem. The spec also says that the attribute parameter and argument are "are constrained by the same rules as simple assignment" - but that would be fine in this case. So I can't see anything in the spec that should disallow this.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
2

Looks like an overloading issue.

TestCaseAttribute has the following constructors:

TestCaseAttribute(object arg);                             // A
TestCaseAttribute(object arg1, object arg2);               // B
TestCaseAttribute(object arg1, object agr2, object arg3);  // C
TestCaseAttribute(params object[] arguments);              // D

Your first example matches (B) as does your third.

You want the second (failing one) to match (A) but in fact it's matching (D)

Try casting your array to an object

[TestCase( (object) new string[] { "1", "2", "3" } )]

or use named parameter passing

[TestCase( arg: new string[] { "1", "2", "3" } )]

The rules of attributes allow one-dimensional array to be passed, but ont two-dimensional arrays (as described here), so (D) is not allowed with an array.

Jasper Kent
  • 3,546
  • 15
  • 21
  • 1
    I understand that it's calling overload D, but why does the fact that it's a `params object[]` parameter matter? The _argument expression_ is still an array creation expression, and can be evaluated to a constant value at compile time. So it should be allowed here, no? – Sweeper Apr 24 '20 at 07:42
  • @Sweeper Explanation added – Jasper Kent Apr 24 '20 at 07:50
  • 1
    I don't think this actually explains it though - it *should* match D by virtue of a `string[]` already being an `object[]`, without any "expansion". I believe this is actually a compiler bug, after looking through the spec. – Jon Skeet Apr 26 '20 at 08:18
  • @JonSkeet I'll check the spec, but this seems like better behaviour than what you're suggesting, certainly in this case. If the `string[]`matched the `params object[]` then the elements would map one-to-one. Thus `SomeTest` would have to have three `string` parameters, not one `string[]` parameter. Also if this is the case now, it would have caused a potentially breaking change when covariant assignment was introduced. Previously passing `string[]` to `object[]` was impossible. When it became possible, even more overloading behaviour would have changed than actually did. – Jasper Kent Apr 26 '20 at 10:53
  • 1
    @JasperKent: No, `string[]` has *always* been convertible to `object[]`. Arrays have been variant since C# 1.0. (It was possibly a design mistake IMO, but it's hard to tell for sure.) Note my answer, which simplifies things by removing the `params` part *and* the overload resolution, and still shows the same problem. – Jon Skeet Apr 26 '20 at 11:24
  • I agree on the design mistake point. Covariant assignment on arrays should not be valid, since array elements are assignable. – Jasper Kent Apr 26 '20 at 11:29
  • Thanks @JasperKent, parameter naming turned out to be the solution for me over here in [this SO question](https://stackoverflow.com/questions/65315556/how-to-pass-string-arrays-into-an-attribute-constructor). – Stanley G. Dec 16 '20 at 15:00