Unit tests failing for CoreLibrary: all ValueArrayTypes tests

[edleno2]

Details about Problem

Last of the CoreLibrary unit test failures. All tests for NFUnitTestTypes/ValueArrayTypes are failing with a NullReference exception.

nanoFramework area: (C# code )
nf-Interpreter

VS version: (2017 | 2019 )

VS extension version:

Target:

Device capabilities output:

Description

All tests fail with a NullReferenceException in IsType for the class type

Detailed repro steps so we can see the same problem

1. Run unit tests in CoreLibrary NFUnitTestTypes/ValueArrayTypes

Other suggested things

Expected behaviour

Sample Project

Screenshot

Additional context

I've made an effort to fix the bug

This is just an issue to hold place for an upcoming fix. Closing a bigger issue first. This is the last of the failing tests for CoreLibrary.

[edleno2]

@josesimoes - I tracked all of these down to the same problem. Each test is using Type.GetType("System.object-name[ ]") which goes to this code: https://github.com/nanoframework/nf-interpreter/blob/52191e10fa825c18b6418fddbca191a3dcf35f24/src/CLR/CorLib/corlib_native_System_Type.cpp#L225. This is the internal native code that can take a string a find the matching typedef in an assembly. However, in this code there is absolutely no logic to handle arrays - the "[ ]" in the strings. Basically finding arrays of objects is not implemented in the Type system.

• I think I may be able to figure out how to support array in the code.
  -- If the string ends with "[]" then first find the object typedef that this is an array of
  -- I have already traced the code that runs when you say obj.GetType() and I see in the case of arrays it is returning a type that is a type of typedef based on reflection - I think that means it was created by the compiler which I do think array of objects do come from.
  -- So I have to then use the typedef I get from the string preceding the "[]" and use it to return a typedef object that looks the typedef that comes back from obj.GetType().
• The only reason for these tests are to confirm that obj.GetType() and Type.GetType(string-with-array-notation) return the same typedef information.

Should I just continue to do this? This is more than a simple test case problem - I'll be implementing a new capability that apparently no one is using at this time. It doesn't look to be a bug as much as a not-implemented issue.

Or did I miss something?

[edleno2]

@josesimoes - ahhh...may have found more. there is a second FindTypeDef function used in that routine that is commented out, and was used to find object types with more complex names. It also doesn't have any checking for arrays, but it is based on returning a CLR_RT_ReflectionDef_Index which is what I think is needed in this case. I think I saw a close issue about these routines being commented out so I'll look at that too.

[josesimoes]

@edleno2 from a quick look at the code you've pointed and the counterpart in mscorlib code that seems to be the case: it's not implemented.

I haven't tested this with the full .NET, but I would assume that obj.GetType() and Type.GetType(string-with-array-notation) do return the same typedef information., right?

Considering all the above, I agree with your proposal to fix (actually implement) this.

[edleno2]

Oops...looking closer I do see the handling for arrays in the commented out code. So I'll work on finding out why that was disabled and fix it.

[edleno2]

And I did check the full .net - it does work with array notation.