Further reduce use of Element in codegen.

pkg/compiler/lib/src/universe/world_builder.dart

Index: pkg/compiler/lib/src/universe/world_builder.dart
diff --git a/pkg/compiler/lib/src/universe/world_builder.dart b/pkg/compiler/lib/src/universe/world_builder.dart
index 05cae632087b4e55bb370f00436ae9f815d95e30..e4dc81d8da18d8acfa68fa18a912d2531d75e954 100644
--- a/pkg/compiler/lib/src/universe/world_builder.dart
+++ b/pkg/compiler/lib/src/universe/world_builder.dart
@@ -21,6 +21,7 @@ import '../universe/function_set.dart' show FunctionSetBuilder;
 import '../util/enumset.dart';
 import '../util/util.dart';
 import '../world.dart' show World, ClosedWorld, ClosedWorldImpl, OpenWorld;
+import 'call_structure.dart' show CallStructure;
 import 'selector.dart' show Selector;
 import 'use.dart' show DynamicUse, DynamicUseKind, StaticUse, StaticUseKind;
 
@@ -1103,6 +1104,11 @@ class ResolutionWorldBuilderImpl implements ResolutionWorldBuilder {
 ///
 /// This adds additional access to liveness of selectors and elements.
 abstract class CodegenWorldBuilder implements WorldBuilder {
+  /// Calls [f] with every instance field, together with its declarer, in an
+  /// instance of [cls].
+  void forEachInstanceField(

[Siggi Cherem (dart-lang), 2017/01/03 17:39:37]

I like the move of this out of the entities.

Couple questions:
 * Does this API include all fields or just fields that are in use (not
tree-shaken)? I'm guessing it's the former, but either way, it might be good to
add a sentence in the dartdoc to be explicit. If we are only including used
fields, consider renaming this to forEachUsedInstanceField (similar to how all
the forEachInvoked* methods below).

 * should we add this API to some other interface too (like
WorldBuilder/ClosedWorld)? It might be too early to tell, but from a quick
glance it seems we use element.forEachInstanceField in a few other places
(constants, creating inference graph, ssa builder). I'm OK crossing that bridge
when we get there and not on this CL, up to you.

[Johnni Winther, 2017/01/04 10:39:49]

Currently all, in time it should be at the world builders discretion. We should
at some point in time (again) be able to tree-shake fields (based on resolution
closed world knowledge) and the caller of this function shouldn't know or care.
I expect it to be in WorldBuilder/ClosedWorld and be used elsewhere, but
currently I'm just growing the interfaces slowly by what is needed by the
refactored use cases.

+      ClassEntity cls, void f(ClassEntity declarer, FieldEntity field));
+
   void forEachInvokedName(
       f(String name, Map<Selector, SelectorConstraints> selectors));
 
@@ -1130,6 +1136,8 @@ abstract class CodegenWorldBuilder implements WorldBuilder {
   ///
   /// Invariant: Elements are declaration elements.
   Iterable<FieldElement> get allReferencedStaticFields;
+
+  CallStructure getCallStructureFor(FunctionEntity entity);
 }
 
 class CodegenWorldBuilderImpl implements CodegenWorldBuilder {
@@ -1202,6 +1210,18 @@ class CodegenWorldBuilderImpl implements CodegenWorldBuilder {
 
   CodegenWorldBuilderImpl(this._backend, this.selectorConstraintsStrategy);
 
+  /// Calls [f] with every instance field, together with its declarer, in an
+  /// instance of [cls].
+  void forEachInstanceField(
+      ClassElement cls, void f(ClassEntity declarer, FieldEntity field)) {
+    cls.implementation
+        .forEachInstanceField(f, includeSuperAndInjectedMembers: true);
+  }
+
+  CallStructure getCallStructureFor(MethodElement element) {
+    return new CallStructure.unnamed(element.parameters.length);
+  }
+
   // TODO(johnniwinther): Remove this hack:
   ClosedWorld get _world =>
       _backend.compiler.resolverWorld.closedWorldForTesting;