Relax some type annotations in concrete type inference.

Relax some type annotations in concrete type inference.

Committed: https://code.google.com/p/dart/source/detail?r=15523

[polux, 2012-11-15 11:07:23]

As discussed offline, the change from FunctionElement to Element on line 1402
was indeed startling since it is assumed to contain FunctionElement only in the
code below.

I've added tests to show why the lists contains indeed Elements and not
FunctionElements only and I've changed the code below to filter out non-function
elements.

In order to test this case I've introduced a magic string literal that has the
unknown type, because there's no other way to obtain it for now. This allows me
to test codepaths guarded by "if (type.isUnknown())" and I have modified some of
the existing tests to take advantage of this.

[karlklose, 2012-11-28 08:15:34]

The annotation fix LGTM, but the string marker feels wrong to me. If we must
have it, can we have it under a flag/parameter to the CPA that is only enabled
in tests?

It seems to me that we never really want unknown in the system unless we use
some form of widening, i.e., collapsing large/infinite concrete types. For your
test, wouldn't it be enough to produce the concrete type [A, B, C, D] and then
call f on it? You can do that by having methods A.foo() => new B(), B.foo() =>
C(), ... and then do
 o = new A();
 while (hest()) { o = o.foo(); }

Even better would be to add infrastructure to the test that allows for creating
an environment of concrete types and then test the effect of one
statement/expression.

[polux, 2012-11-29 11:49:07]

On 2012/11/28 08:15:34, karlklose wrote:
> The annotation fix LGTM, but the string marker feels wrong to me. If we must
> have it, can we have it under a flag/parameter to the CPA that is only enabled
> in tests?
> 

Yes, if we stick to that solution.

> It seems to me that we never really want unknown in the system unless we use
> some form of widening, i.e., collapsing large/infinite concrete types.

Yes that's the plan. That and external method which didn't declare return types.

> For your
> test, wouldn't it be enough to produce the concrete type [A, B, C, D] and then
> call f on it? You can do that by having methods A.foo() => new B(), B.foo() =>
> C(), ... and then do
>  o = new A();
>  while (hest()) { o = o.foo(); }
> 

That wouldn't test the codepath that copes with dynamic.

> Even better would be to add infrastructure to the test that allows for
creating
> an environment of concrete types and then test the effect of one
> statement/expression.

Yes that would be ideal... let me see if I can come up with something and I'll
ping this thread.

[polux, 2012-11-29 15:49:16]

I've restricted the string hack to tests and will remove it as soon as we can
infer dynamic easily.

[ahe, 2012-11-29 15:50:58]

Patch set 4, LGTM