Fix code-size regression

This reinserts the native spec-string interpretation.

The CL https://codereview.chromium.org/2004833003/ changed the interpretation of `List` from `List<E>` to `List<dynamic>` causing these native classes to be added through subtyping:

NativeUint8List <: List
NativeUint8ClampedList <: List
NativeUint32List <: List
NativeUint16List <: List
NativeInt8List <: List
NativeInt32List <: List
NativeInt16List <: List
NativeFloat64List <: List
NativeFloat32List <: List
NativeTypedArrayOfInt <: List
NativeTypedArrayOfDouble <: List

R=sra@google.com

Review URL: https://codereview.chromium.org/2021723003 .
This commit is contained in:
Johnni Winther 2016-06-02 10:16:44 +02:00
parent a6b93661fd
commit 565b30123c
2 changed files with 15 additions and 6 deletions

View file

@ -520,12 +520,21 @@ abstract class NativeEnqueuerBase implements NativeEnqueuer {
.isSubtype(type, backend.listImplementation.rawType)) {
backend.registerInstantiatedType(type, world, registry);
}
// TODO(johnniwinther): Improve spec string precision to handle type
// arguments and implements relations that preserve generics. Currently
// we cannot distinguish between `List`, `List<dynamic>`, and
// `List<int>` and take all to mean `List<E>`; in effect not including
// any native subclasses of generic classes.
// TODO(johnniwinther,sra): Find and replace uses of `List` with the
// actual implementation classes such as `JSArray` et al.
enqueueUnusedClassesMatching((ClassElement nativeClass) {
InterfaceType nativeType = nativeClass.thisType;
InterfaceType specType = type.element.thisType;
return compiler.types.isSubtype(nativeType, specType);
}, cause, 'subtypeof($type)');
return;
}
assert(type is DartType);
enqueueUnusedClassesMatching(
(nativeClass) => compiler.types.isSubtype(nativeClass.thisType, type),
cause,
'subtypeof($type)');
assert(type is VoidType || type is DynamicType);
}
// Give an info so that library developers can compile with -v to find why

View file

@ -69,7 +69,7 @@ void main() {
// 2. Some code was refactored, and there are more methods.
// Either situation could be problematic, but in situation 2, it is often
// acceptable to increase [expectedMethodCount] a little.
int expectedMethodCount = 449;
int expectedMethodCount = 432;
Expect.isTrue(
generatedCode.length <= expectedMethodCount,
'Too many compiled methods: '