By 'appearing as not being called' I mean the typed selector for the call site for 'resolve' has a type of [empty], which prevents it matching any method, including _StaticAnnotationUriResolver.resolve.
This is because the type of receiver is assigned

It seems like type inference does not see that the closure XXX is called, leading to over-aggressive optimization of subsequent code.

class ShadowDomComponentFactory implements ComponentFactory {
  final Expando _expando;

  ShadowDomComponentFactory(this._expando);

  FactoryFn call(dom.Node node, DirectiveRef ref) {
    return (Injector injector) { <-----------------XXXX
        ...
      };
  }
}

From the --dump-info:
+library angular.core.dom_internal 112866 bytes (7%) package:angular/core_dom/module_internal.dart
  ...
  +class ShadowDomComponentFactory implements [ ComponentFactory, Object ]
    +field /* Expando / final _expando 0 bytes (0%)
    +method / (Node, DirectiveRef) -> FactoryFn / call 1153 bytes (0%)
      Inferred parameter node [null|subclass=Object]
      Inferred parameter ref [null|subclass=Object]
      Inferred return type [subtype=Function]
      Inferred side effects Depends on nothing, Changes static.
      Generated code 136 bytes (0%)
      function(node, ref) {
        return new Y.ShadowDomComponentFactory_call_closure(this, node, ref);
      }
      +closure / (Injector) -> dynamic */ <unnamed> 1017 bytes (0%) <-------------------------XXX
        Inferred parameter injector [empty]
        Inferred return type [empty]
        Inferred side effects Depends on [] field store static store, Changes [] field static.

Even though the code is unreachable as evidenced by the [empty] type, quite a lot of code is generated along that path.
It might be a good idea to generate 'throw "Unreachable"' as the entire body of any method which has some parameter inferred as [empty]. This would tree-shake out more code rather than leave it in an incorrectly optimized state and cause the failure to be closer to the type inference bug.

cc @herhut-ggl.

This repro demonstrates the problem:

class F {
  call() => (x) => new G(x.toInt());
}

class G {
  var z;
  G(this.z);
  foo() => '$this.foo';
  toString() => 'G($z)';
}

main() {
  var f = new F();
  var m = {};
  m['a'] = f();

  print(m'a'.foo());
}

out.js:775: TypeError: undefined is not a function
      return new A.G(x.toInt$0(0));
                       ^
TypeError: undefined is not a function
    at F_call_closure.call$1 (out.js:775:24)
    at dart.main (out.js:763:29)

x has inferred type [empty].
The body is optimized under that assumption. 'x' does not match any interceptor types, so the call is generated directly.
The body should have either J.JSNumber_methods.toInt$0(x) or some other interceptor-style call.

Stefan - do you know why the function parameters are [empty]?

cc @floitschG.
Set owner to @herhut-ggl.

Added Accepted label.

The fix for this is probably worth merging to the 1.3 branch if it's simple enough. Please file a merge request if so (Label: MergeToStable).

cc @ricowind.

Tracing of closures did not consider the [call] member of instances of [Function] to be closures themselves. The fix in r35417 makes the tracer consider all invocations of [call] methods to be a closure call.

Added Fixed label.

This comment was originally written by vmend...@gmail.com

This is still happening to me in 1.4.0, particularly in DefaultTransformDataHttpInterceptor and only in checked mode.

Attachment:
CheckedMode.png (168.71 KB)

Removed this from the 1.4 milestone.
Added Started label.

This comment was originally written by vmen...@gmail.com

herhut: Are you able to reproduce this? Do you need any help to reproduce it? It seems simple, just a regular angulardart project compiled in checked mode, but just tell me if you don't have clues of what's happening and I'll try to help.

Thanks

I have a fix for this but due to recent holidays in Denmark it took a little longer than usual to get it in. This will be fixed soon.

This has been fixed as of r36984.

Added Fixed label.