Need spec and compile-time errors of incorrect JS interop usage

[jmesserly]

There are many invalid things that can be done with JS interop, but we don't have static errors for this.

Here are some examples of things that should be reported (or else, need to be specified and fixed in the DDC/dart2js):

• an anonymous JS class with positional arguments in the constructor. This is invalid, because it's supposed to create an object literal, and causes a DDC crash (see Error compiling dartdevc module #32031)
• use of generic functions/methods (currently unsupported in JS interop)
• use of generic classes (what is intended behavior?)
• use of @JS on a class/library member without a @JS on the library
• use of @JS on a class member instead of external
• declaring Dart members on a @JS class (Dart code is silently ignored)
• extends/mixin@JS classes from a Dart class (also unclear if implements is supported)
• extends/mixin/implements Dart class from @JS class

Errors should be reported from Analyzer so people can see the problem sooner. (Once DDC migrates to Kernel, need a way of calling into Analyzer to produce these kinds of errors. Or we just have shared code between dart2js/DDC for validating JS interop usage.)

---

Also it would be lovely to have a specification. These would be useful:

• where is @JS allowed to appear?
• where is external allowed to appear?
• inheritance implications of the various permutations of Dart and JS classes and member kinds
• interaction with Dart generic classes
• interaction with Dart generic methods/functions
• meaning of Dart members on a JS class
• semantics of anonymous JS types
• how JS types fit into the Dart subtyping relation and Dart Type equality
• how JS functions related to the Dart type system
• static and dynamic call/get/set/index/operator/tearoff semantics
• behavior of dart:core Object members (toString, hashCode, operator ==, noSuchMethod, runtimeType) for JS objects
• interaction with the JS global namespace
• interaction with JS modules

[sigmundch]

Once DDC migrates to Kernel, need a way of calling into Analyzer to produce these kinds of errors. Or we just have shared code between dart2js/DDC for validating JS interop usage.

My preference is for the latter: I can imagine we'd have a js-interop checker implemented as a kernel-visitor that we can both share.

[matanlurey]

It would be ideal for the analyzer to give errors/warnings before a compilation failure, if possible.

(It's not clear to me we have a good strategy yet for web/JS-specific analyzer checks, so maybe we need a thread/doc/discussion about that separate from js-interop checking in the compilation pipeline)

[jmesserly]

Yeah for JS interop, we can have shared checks between DDC/dart2js/Analyzer. That way they show up in IDE as well as compilers.

At the moment I don't really care where the checks live :) ... I'm mostly concerned that JS interop is completely unchecked and there's all kinds of undefined behavior people can, and do stumble into.

(And personally, when I have to touch DDC's implementation code for JS interop, I have no idea what's supposed to be legal or not, so it's really difficult to refactor any of the code that touches that.)

[matanlurey]

@vsmenon and I just ran into a client internally with another edge, non-`abstract classes, i.e.:

@JS()
library js_interop;

import 'package:js/js.dart';

@JS()
@anonymous
class Animal {
  external String get name;
  external set name(String name);
}

This should probably be a compile-time error, as it implicitly creates a default constructor.

The correct implementation would be:

@JS()
@anonymous
abstract class Animal {
  external String get name;
  external set name(String name);
}

Or, with an external factory constructor.

• In DDC, everything above appears to work as if this was abstract
• In Dart2JS above creates a Dart class with a JS-semantics getter/setter.

[lrhn]

Nitpick: The second class also gets a default constructor, you just can't use it to instantiate the abstract class. You can extend the class, though, which should probably also be disallowed.