co19: Un-optimizable test 'check' function

[DartBot]

This issue was originally filed by zundel@google.com

---

co19/LibTest/core/Queue/Queue.from/Queue/Queue.from/A01/t01
co19/LibTest/core/Queue/Queue.from/Queue/Queue.from/A01/t02

file:/home/zundel/dart/tests/co19/src/LibTest/core/Queue/Queue.from/Queue_Queue.from_A01_t02.dart/Queue_Queue.from_A01_t02.dart:48: List<<dynamic>> has no method named "removeFirst"
    47: c.forEach(void compare(var element) {
    48: Expect.isTrue(l.removeFirst() == element);

void check(List l, Collection c) {
  Expect.isTrue(l.length == c.length);
  c.forEach(void compare(var element) {
    Expect.isTrue(l.removeFirst() == element);
  });
}

removeFirst() is not a method on List or its superclasses, hence the type error. When optimized, the removeFirst() method from the Queue object might be pruned because there are no references in the program to Queue.removeFirst(). I don't think the test needs to be written this way, maybe just change check() to take a Queue instance for the first parameter, or do something other than removeFirst() to test the first element.

@peter, do you think we need a label below to categorize tests in general, maybe co19 tests in particular?

[peter-ahe-google]

I think this test exposes a bug in how dartc optimizes, so I'd like to keep it as is.

Correct me if I'm wrong, but this test works fine in checked mode, right? If so, it must also work in optimized mode.

Assigning back for clarification.

---

Set owner to zundel@google.com.

[DartBot]

This comment was originally written by zundel@google.com

---

Yes, the code works fine without types, but some of the preliminary "tree shaking" or pruning of dead code probably broke the test.

The contract with the optimizing compiler was that it was allowed to make assumptions based on types - my analysis is that this code doesn't make any sense with types in place. As this little wrinkle is not the primary object of the test, I suggest it be removed.

I suggest you write a second test for calling methods that don't exist in types if you insist that should work, but you'll probably get some resistance on down the line when someone starts caring about the size of optimizing code.

---

Removed the owner.
Added Area-Language, Triaged labels.

[peter-ahe-google]

Dartc is allowed to optimize under the assumption that there is no heap pollution. This is not heap pollution.

If someone calls a method that does not exist in an interface, this should feed back into whatever assumptions are made about types. This is a bug in dartc, not the test.

---

Removed Area-Language label.
Added Area-Compiler label.

[DartBot]

This comment was originally written by zundel@google.com

---

You can make this a compiler issue if you want, but let me just interject why I think this is a language issue.

There is nothing a compliance test can do to test this at the moment because AFAIK, there is no contract with what an optimizing compiler can and cannot do when the use of a type doesn't match its definition, just a misunderstanding that we aren't any closer to resolving.

All we can say today is that when optimizing is off, we should run without problem. When optimizing is on and there are static type errors, the expectations are not defined. I think it makes sense to define this in spec because, the more assumptions the optimizer is allowed to make, potentially the more optimizations are possible. If no further assumptions are possible, then the optimizer is going to be hamstrung and ineffective.

[peter-ahe-google]

Any Dart compiler must implement the specification.

When compiling to JS there is an exception: the compiler is allowed to optimize under the assumption that there is no heap pollution.

This means that if a program runs without throwing type assertions in checked mode, it must also run when compiled to JS in optimized mode.

The exception is a stop-gap measure. We hope to eliminate it. However, if we cannot eliminate it, the spec will be changed to include it. From the perspective of dartc, just assume that the spec includes the exception.

This exception only applies to JS because it is a challenge to generate efficient code for that target. The exception does not transfer to other target platforms, as these platforms do not have the same limitations as the JS platform.

Here is an example of what the exception allows dartc to do:

int i = "fisk";
int j = {};
i + j; // This can be compiled to JS: i + j.

Here is an example of something that the dartc compiler is expected to handle correctly:

Object s = "foo";
print(s.length);

[DartBot]

This comment was originally written by zundel@google.com

---

I'm not personally planning to work on this issue any further, that's why I recommend you encode your understanding of the limits of optimization into the spec. For example, I couldn't find the term 'heap pollution' in the spec either.

[DartBot]

This comment was originally written by zundel@google.com

---

No more code generation in dartc, so this is no longer an issue.

---

Added WontFix label.