Re-apply: Inside a generative constructor, "this" is created at the very end. So we have to use the…

Re-apply: Inside a generative constructor, "this" is created at the very end. So we have to use the type variables provided in the parameters.
Committed: https://code.google.com/p/dart/source/detail?r=19309

[ngeoffray, 2013-03-01 12:00:11]

Patch set 1 contains the original CL. Patch set 2 contains the fix.

[kasperl, 2013-03-01 12:05:34]

LGTM.

https://codereview.chromium.org/12389046/diff/6001/sdk/lib/_internal/compiler...
File sdk/lib/_internal/compiler/implementation/ssa/builder.dart (right):

https://codereview.chromium.org/12389046/diff/6001/sdk/lib/_internal/compiler...
sdk/lib/_internal/compiler/implementation/ssa/builder.dart:1169: // If
[superclass] needs rti, we have to give a value to its
rti -> RTI

[ngeoffray, 2013-03-01 12:14:07]

Thanks Kasper.

https://codereview.chromium.org/12389046/diff/6001/sdk/lib/_internal/compiler...
File sdk/lib/_internal/compiler/implementation/ssa/builder.dart (right):

https://codereview.chromium.org/12389046/diff/6001/sdk/lib/_internal/compiler...
sdk/lib/_internal/compiler/implementation/ssa/builder.dart:1169: // If
[superclass] needs rti, we have to give a value to its
On 2013/03/01 12:05:34, kasperl wrote:
> rti -> RTI

Done.

[karlklose, 2013-03-01 12:15:22]

https://codereview.chromium.org/12389046/diff/6001/sdk/lib/_internal/compiler...
File sdk/lib/_internal/compiler/implementation/world.dart (right):

https://codereview.chromium.org/12389046/diff/6001/sdk/lib/_internal/compiler...
sdk/lib/_internal/compiler/implementation/world.dart:58:
compiler.enqueuer.resolution.seenClasses.forEach(addSubtypes);
Could we create constraints to track this dependency instead of adding all the
classes?

https://codereview.chromium.org/12389046/diff/6001/sdk/lib/_internal/compiler...
sdk/lib/_internal/compiler/implementation/world.dart:71: // TODO(ngeoffray):
This should use subclasses, not subtypes.
I find this use of subtypes confusing, because they are really classes and not
types. It is also inconsistent with the pair superclass/supertype, where the
latter is indeed a type.

[ngeoffray, 2013-03-01 12:39:27]

https://codereview.chromium.org/12389046/diff/6001/sdk/lib/_internal/compiler...
File sdk/lib/_internal/compiler/implementation/world.dart (right):

https://codereview.chromium.org/12389046/diff/6001/sdk/lib/_internal/compiler...
sdk/lib/_internal/compiler/implementation/world.dart:58:
compiler.enqueuer.resolution.seenClasses.forEach(addSubtypes);
On 2013/03/01 12:15:22, karlklose wrote:
> Could we create constraints to track this dependency instead of adding all the
> classes?

We could put a rti dependency. This would require to find classes seen but not
instantiated and check if any of its supertype needs rti (if we don't want to
add bogus rti dependencies in the rtiDependencies map).

Looks simpler though to just poulate them in the subtypes tree. I don't think it
affects negatively the generated code or the compiler. Maybe since you're
asking, you thought about a case where it would matter?

https://codereview.chromium.org/12389046/diff/6001/sdk/lib/_internal/compiler...
sdk/lib/_internal/compiler/implementation/world.dart:71: // TODO(ngeoffray):
This should use subclasses, not subtypes.
On 2013/03/01 12:15:22, karlklose wrote:
> I find this use of subtypes confusing, because they are really classes and not
> types. It is also inconsistent with the pair superclass/supertype, where the
> latter is indeed a type.

Yes, this is mostly for historic reasons. I don't think we had proper DartType
when we started to have the subtypes set.

[ngeoffray, 2013-03-01 13:18:16]

Committed patchset #3 manually as r19309 (presubmit successful).

[karlklose, 2013-03-01 13:23:39]

https://codereview.chromium.org/12389046/diff/6001/sdk/lib/_internal/compiler...
File sdk/lib/_internal/compiler/implementation/world.dart (right):

https://codereview.chromium.org/12389046/diff/6001/sdk/lib/_internal/compiler...
sdk/lib/_internal/compiler/implementation/world.dart:58:
compiler.enqueuer.resolution.seenClasses.forEach(addSubtypes);
No, I don't have a case in mind.