cc @larsbak.

Added this to the 1.7 milestone.
Removed Priority-Unassigned label.
Added Priority-High label.

cc @bwilkerson.
cc @stereotype441.
Set owner to @jwren.

For those unfamiliar with the code in question, here are the relationships at issue:

• CapturedVariable is an abstract base class.
• Only two concrete classes are descendants of it: ClosureFieldElement and BoxedFieldElement, both of which directly implement CapturedVariable.
• Both ClosureFieldElement and BoxedFieldElement also implement Element (indirectly, via their shared base class, ElementX)
• The code which generates the warning looks like this:

    closureData.forEachCapturedVariable((variable, field) {
      locals.setCaptured(variable, field);
    });

• closureData.forEachCapturedVariable's argument has type void f(Local variable, CapturedVariable field). Therefore in the above code, Analyzer infers that the propagated type of "field" is CapturedVariable.
• locals.setCaptured's second argument has type Element.
• Since Element doesn't derive from CapturedVariable, and CapturedVariable doesn't derive from Element, neither is considered assignable to the other, there is a type mismatch. Analyzer issues a hint for the type mismatch (rather than a warning) because the type information was based on propagated types rather than explicitly declared types.
• It could be argued that the code is currently safe, because all of the concrete descendants of CapturedVariable are also descendants of Element.
• It could also be argued that there is a danger of a future bug occurring, since someone might in the future add a class that derives from CapturedVariable and does not derive from Element; if they did so, then the code in question would no longer be safe.

I can see a few ways we could fix this:

1. For purposes of hint generation, permit type X to be assigned to Y if all concrete descendants of X are also descendants of Y. This has the advantage of matching the reasoning that leads us to conclude that the code is currently safe. It has the disadvantage of failing to alert the user to the potential future danger if a new class is added that descends from X but not Y.
2. For purposes of hint generation, permit type X to be assigned to Y if there exists a concrete descendant of X that is also a descendant of Y. This has the disadvantage that it's not actually sound--just because a concrete class exists that descends from both X and Y doesn't mean that the particular object that will be encountered at runtime will be of that type.
3. Modify dart2js's declaration of CapturedVariable to capture the fact that all concrete implementations of it can reasonable be assumed to be Elements:

  abstract class CapturedVariable extends Element {}

Personally I would favor alternative 3.

Removed Priority-High label.
Added Priority-Medium label.

Removed this from the 1.7 milestone.
Added this to the 1.8 milestone.

Since this is assigned to the 1.8 milestone, I'm bumping the priority to high. Feel free to lower the priority and remove the 1.8 milestone marker.

Removed Priority-Medium label.
Added Priority-High label.

Removed the owner.

Removed this from the 1.8 milestone.
Removed Priority-High label.

Added Priority-Medium label.

Assumed stale.