Native methods from dart:html and friends can be aggressively inlined.

Given...

    @­JSName('jsfoo') int foo(int x) native;

... we can inline a Dart call "a.foo(b)" and generate, instead of "a.foo$1(b)", the inlined code "a.jsfoo(b)".

The foo$1 wrapper performs several functions. These are known in the compiler so can be generated or checked in the inlined code without implementing full inlining. They are (1) arity check (2) type annotation checks (in checked mode) (3) (rare) some conversions (wrapping callables in JS functions).

In checked mode we need to satisfy the checks that are inserted into foo$1, i.e. the precondition (b is int) needs to hold.

We can be more general that requiring "a" to be at one point in the inheritance hierarchy - this is especially important for SVG where many methods are inherited from secondary interfaces and explicitly implemented.

Considering the set of concrete types at "a":
If ...

1. all types implement foo accepting on argument, or the type does not accept 'foo' with one argument and also does not implement noSuchMethod,
2. all implementations of foo are by a native method named 'jsfoo',
3. (checked mode) the arguments satisfy the intersection of type annotations constraints for the parameters,
4. no parameter type of any of the implementations needs a conversion.

... then we can replace "a.foo$1(b)" with "a.jsfoo(b)".

These conditions can often be satisfied with no knowledge of the type of "a", e.g. the name "foo" is used only by native class methods and no classes implement noSuchMethod.
We arrange via method and field name generation that no other types use the names of native methods and fields, so there can be no accidental call to some other element called "jsfoo".