[ddc] Add an API for the debugger to easily identify native JS objects and errors

[annagrin]

The debugger (dwds) needs to

• find if the type of the variable is not related to dart so the variable does not need to be displayed in the UI

  • note that we do want do display certain JS types such as JS arrays, maps, sets, bools, ints, etc.

• find if the type of the variable corresponds to a JS error and needs to be mapped to dart stack trace.

Currently we rely on type names for identifying those, which was proven to be fragile in the past.

See the latest example in dart-lang/webdev#1821

Suggestion:

• define ddc runtime API, ie isNativeJavaScriptError(object) and isNativeJavaScriptObject(object).
• we can evaluate expressions like require('dart_sdk').dart.isNativeJavaScriptError(object) to use them in the debugger.

[nshahan]

@srujzs
We should add this API to the DDC runtime and have tests that break when we make changes to the JS interop representations.

[srujzs]

Would we still need this API if we start exposing JS types e.g. JSMap, JSObject, etc.? I think in the past this was fragile because we were relying on internal representations (Interceptors), and not external representations.

If I'm understanding this correctly, we'd like to tell if this is not a Dart type and also not one of several JS types. We also want to tell if a variable is a JS Error type.

I think this is doable with a combination of is checks and instanceof with the JS types.

[annagrin]

@srujzs I think using JS types and instanceOf is more stable, as long as we never need to detect an internal type. Will all the current errors be direct instances of Error, or is there going to be a class hierarchy similar to what we have now?

[annagrin]

@srujzs what needs to be done here to expose JS types? Could adding a ddc runtime API be an easier (even if temporary) solution for now so we prevent dwds from breaking on such changes?

[srujzs]

Will all the current errors be direct instances of Error, or is there going to be a class hierarchy similar to what we have now?

Can you explain a bit more what you're looking for here? Like subtypes of Error? I'm not sure if we're going to introduce a JS type for Error (although we certainly could), so I'd like to make sure I understand all the use cases here.

what needs to be done here to expose JS types? Could adding a ddc runtime API be an easier (even if temporary) solution for now so we prevent dwds from breaking on such changes?

We have some JS types exposed via dart:js_interop, but they're very much in flux for the next few months, so I think adding an API to DDC is certainly reasonable in the meantime. I remember coming across this in the past too, so it's worth it to not break dwds.

[sigmundch]

FYI - I just came across this issue while investigating #52572. My current change to address that other issue is to remove the coupling between NativeError and Error in the DDC layer, doing this may affect some of the behavior in dwds because we are asking queries about JavaScript using the internal Dart types.

Exposing helpers in the DDC runtime seems like it may be the most robust way to improve this. Another option here is to directly identify native objects within JavaScript, but I get the impression it will not be as robust, since we do sometimes map native types to Dart types.

[annagrin]

This is superseded by work in dart-lang/webdev#1949