Florian has been working on this today (and can repro locally).

Set owner to @fsc8000.
Added this to the 1.3 milestone.
Removed Priority-Unassigned label.
Added Priority-High, Area-VM, Triaged labels.

There are two conflicting "Animation" classes in the system coming from different places: One from angular.animate, the other from dart.dom.html.

Two issues here: The VM does not report the name conflict, the other issue is where the other Animation class from dart:html comes from.

The following "fix" made the problem disappear: I don't know yet where the dart.dom.html.Animation comes from.

diff --git a/test/_specs.dart b/test/_specs.dart
index 75d7906..b55a137 100644

--- a/test/_specs.dart
+++ b/test/_specs.dart
@@ -8,7 +8,7 @­@ import 'package:collection/wrappers.dart' show DelegatingList;
 
 import 'jasmine_syntax.dart' as jasmine_syntax;
 
-export 'dart:html';
+export 'dart:html' hide Animation;
 export 'package:unittest/unittest.dart';
 export 'package:unittest/mock.dart';
 export 'package:di/dynamic_injector.dart';

Removed Area-VM label.
Added Area-Dartium label.
Marked this as being blocked by #17652.

fwiw Animation comes from ./third_party/WebKit/Source/core/animation/Animation.idl. This interface appeared after we rolled Dartium forward to M34, it was not there before.

Yes, that type was added in M34. I thought type from user libs took precedence exactly for this reason. I.e., from the spec:

"If a name N is referenced by a library L and N would be introduced into the top level scope of L by an import from a library whose URI begins with dart: and an import from a library whose URI does not begin with dart::
The import from dart: is implicitly extended by a hide N clause.
A static warning is issued."

This suggests that the explicit hide Florian added should be unnecessary.

cc @blois.
cc @gbracha.
Removed Area-Dartium label.
Added Area-VM label.

Regarding comment #­5:
Vijay what you are quoting refers to imports. The thing here is that this code is exporting conflicting names.

The problem is "an import from a library whose URI begins with dart:"

In this case dart:html is being exported, so the import that contains Animation is not a dart: import.

To guard against breaking changes here the logic would have to be that types originating from dart SDK libraries are shadowed rather than types introduced via dart: imports.

Marked this as being blocked by #6134.
Unmarked this as being blocked by #17652.

I think this is an issue in the spec (filed issue #17678). The Animation pulled in from the user library should be preferred over the one (indirectly) pulled in from dart:html.

Marked this as being blocked by #17678.

Kasper, to be clear what you want is that a name which originates in dart:* libraries, however circuitous, is hidden automatically behind the users back in case of conflicts. Is that correct?

cc @mhausner.
Removed the owner.
Removed this from the 1.3 milestone.
Removed Priority-High label.
Added Priority-Medium label.
Changed the title to: "Track dart: origin of names in order to resolve conflicts".*

The intent is that we can add things to a dart:* library without causing a conflict with something from a user library. To achieve this we need to make sure it works through arbitrary re-exports, so your interpretation of what the spec requires (aka what I want) is correct.