Enable string properties evaluation of Length and Char[].

[ilonatommy]

Without this PR evaluation of:
str.Length
str[0]
results in unable to evaluate.

The problem is that we don't get the properties of string from runtime, only its value.

• To get them, we granted objectId to strings by saving on the debugger side their stringId by which they are identified on the runtime side (see: changes in JObjectValueCreator.cs).
• We agreed that since strings have objectId now, their methods should be invoked the same way as objects's methods - on the runtime side - it seems logical in this situation.
• Another major change is to respect polymorphism when invoking a method - we used to take into consideration only one of all possible methods of methodName in GetMethodIdsByName(). Now we are looking through all of them to make sure none matches the form passed in the expression. Existing tests were enough to test it, e.g. Split has 10 different forms.
• Changes in EvaluateExpression.cs are connected with correcting a merge error: both ConvertCLRToJSType and ConvertCSharpToJSType were existing, doing the same job but we were not using one of them. This PR merges them into one function as it was supposed to be.

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Needs fixing indexing with expressions before all the tests will be able to pass.

Author:	ilonatommy
Assignees:	ilonatommy
Labels:	arch-wasm, area-Debugger-mono
Milestone:	-

[ilonatommy]

/azp run

[azure-pipelines]

You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list.

[lewing]

could we add an extra field with the id and use the object logic?

[ilonatommy]

could we add an extra field with the id and use the object logic?

We would have to introduce this objectId on the runtime side then and that's the biggest problem. It's possible but complicated, that's why I decided on a not too neat but easy fix. @thaystg, you would probably assess it better. Does it pay off to add objectIds for strings for the purpose of its 2 properties evaluation in the debugger?

[thaystg]

Yes, for string is not so difficult as we already have an string_id on runtime side. We just need to change the browserDebugProxy side.

[thaystg]

I'm not sure what is the best approach, because the way that is implemented we only need to "go to" runtime once, to get the string value, and the rest is resolved on BrowserDebugProxy side.
If we implement using string_id, we would need to "go to" runtime twice, and I don't know if we really need to do it, once we already have the string value.

[ilonatommy]

The current state is that we are able to get some information for strings using the same methods that we are using for objects. If we will be able to get properties the same way, then we agreed on editing this PR and resolving string's properties and also methods on strings. on the runtime. If it's not a case then we will stick to debugger side for both and the PR will not be changed.

[radical]

Can't we fallback to compiling the expression, since we have the string value? roslyn can take care of indexing, or properties on the string.

[radical]

string local_str = "foobar"; // this is the value that we have
return local_str[0] // or local_str.Length

Same as what we do for other stuff.

[ilonatommy]

GetObjectMemberValues that we are normally using for objects is working for a string as well, a reply for getCommandType = GetObjectCommandOptions.WithProperties | GetObjectCommandOptions.ForDebuggerDisplayAttribute:

  "result": [
    {
      "value": {
        "type": "number",
        "value": 4,
        "description": "4"
      },
      "writable": true,
      "isOwn": true,
      "name": "_stringLength",
      "__state": null,
      "__section": "internal"
    },
    {
      "value": {
        "type": "symbol",
        "value": "I",
        "description": "73 'I'"
      },
      "writable": true,
      "isOwn": true,
      "name": "_firstChar",
      "__state": null,
      "__section": "internal"
    },
    {
      "get": {
        "type": "function",
        "objectId": "dotnet:method:{\"containerId\":5,\"isValueType\":false,\"methodId\":9}",
        "className": "Function",
        "description": "get Length ()"
      },
      "name": "Length",
      "isOwn": true,
      "__section": "result",
      "__state": null
    }
  ],
  "privateProperties": [],
  "internalProperties": []
}

So the problem of Length property is solved easily by granting "objectId" to the string. It does not solve indexing yet.

[ilonatommy]

Can't we fallback to compiling the expression, since we have the string value? roslyn can take care of indexing, or properties on the string.

What you said it true, Roslyn can take care of indexing and properties and that's what this PR was originally doing. I guess you meant that we should not add the logic for this problem to Resolve but rather edit only CompileAndRunTheExpression. But CompileAndRunTheExpression is using Resolve underneath, so the changes there are required anyway in the original approach.

Because we succeeded in granting objectIds for strings, properties problem will be solved the same way as we solve it for objects - talking to runtime. We will avoid confusing people when reading the code this way and avoid making a special "properties extraction process" only for string schema.

[ilonatommy]

Failures in staging are caused by #70983.

[thaystg]

There are failures on CI.