fasta: Type values obtained from a typedef should represent the underlying type, not the typedef

[sigmundch]

Edit by eernstg, Apr 6 2018: This is now the fasta specific issue for #32782.

---

We represent typedefs as function types when the typedef is used as a value. This is problematic because it breaks when using the == operator and printing.

Here is simple repro:

typedef int F();
typedef int G();

main() {
 var x = F;
 print(x);
 print(F == G);
}

Running this prints F and false on the VM, but () => int and true if using fasta.

For context - this issue was discovered while trying to compile an app with dart2js, I don't believe there is a work around on our side.

[lrhn]

Fasta is correct.
The Type object corresponding to a function type must be equal to another Type object representing the same function type. Function types are structural, so F and G both represent the function type dynamic Function(), so their corresponding Type objects must be equal.

The toString of Type objects is not specified anywhere, so it can't be wrong.
To be even marginally useful, we should decide on something and do the same thing in every implementation. Either be completely opaque ("Function") or provide something easily parsable - because then people will parse them no matter how much we discourage it - say dynamic Function(), now that we actually have an in-language syntax for function types.

[sigmundch]

Thanks @lrhn for clarifying.

If that is the case, this might mean we need to fix all implementations to match the structural equality. I believe right now both the VM and dart2js have the nominal semantics. We have also seen angular apps that use typedefs as keys in DI maps and that might break if we change this.

/cc @hterkelsen - do you know how much of a breaking change this would be?

[lrhn]

For the record, the Fasta behavior is likely the result of a mail discussion we had between the Kernel and language teams (and probably a few other people) back in January about the shortcomings of the specification around Type objects.

The specification, and class documentation, is silent on, well, everything. The entirety of the documentation on Type objects from library and specification is the sentence "Runtime representation of a type."

The specification tells us how to create Type objects as:

If d is a class or type alias T, the value of e is an instance of class Type (or a subclass thereof) reifying T.

That's vague enough that I can't decide whether F represents the declaration or the type. If it's the declaration, then the Type object really is nothing but a token that is usable by the mirror system, and we should never use it for anything else. That would make them completely useless if you don't use the mirror system
Since Type objects otherwise represent types (they are the return values of .runtimeType), I'd go with types over declarations. The current representation of typedefs seem to favor the "declaration" interpretation.

In either case, there is not enough specification to make any behavior formally right or wrong.

There is, however, desirable behavior, and if the Type object is to be useful for anything except reflection, it needs to be equal to other objects representing the same type.
Example:

typedef F();
class C<T> { get type => T; }   // Another way to extract a type.
main() { 
  print(F == new C<F>().type);  
}

If this doesn't print true, then I hope we can agree that the type object corresponding to F is truly useless.

It prints false in dart2js and true in the VM. Only halfway useless.

Another example:

typedef F();
typedef G();
main() {
  print(<F>[].runtimeType == <G>[].runtimeType); 
}

Again, I'd want this to be true. It's true in dart2js, false in the VM.

[harryterkelsen]

I'll try to get some numbers on if we have customers making use of the "declaration interpretation"

[sigmundch]

we are still investigating whether the fix should be in dart2js instead - I've marked this as "low" to indicate somehow that this is not something the FE team should actively look into yet.

[lrhn]

Is this issue fixed (as in F==G being true) by switching everybody to the common front-end, or do we still need back-ends to change?

[eernstg]

I suspect that the current title ('Do not convert typedefs used as values to a type') is misleading given that the goal is now to ensure that Type entities obtained from type aliases should represent the underlying (structural) type rather than being opaque tokens for the type alias itself. I'll adjust the title accordingly.

[sigmundch]

Yes - I think we can close this issue as working as intended

[eernstg]

Are you sure it is working? I just checked, and here's an excerpt from a trybot log, showing that the configuration includes dart2js --use-kernel --strong , which I interpret to mean that it is relevant for 'area-front-end' and 'Customer-dart2js':

Running "dart2js" command: DART_CONFIGURATION=ReleaseIA32 out/ReleaseIA32/dart-sdk/bin/dart2js --sync-async --generate-code-with-compile-time-errors --test-mode --allow-mock-compilation --categories=all --minify --use-kernel --strong --packages=/b/swarming/w/ir/.packages /b/swarming/w/ir/out/ReleaseIA32/generated_tests/language_2/enum_syntax_test_07.dart --out=/b/swarming/w/ir/out/ReleaseIA32/generated_compilations/dart2js-strong-minified-sdk/multitest_language_2_enum_syntax_test_07/out.js
FAILED: dart2js-d8 release_ia32 language_2/type_alias_equality_test/01
Expected: Pass
Actual: RuntimeError
--- Command "dart2js" (took 866ms):
DART_CONFIGURATION=ReleaseIA32 out/ReleaseIA32/dart-sdk/bin/dart2js --sync-async --generate-code-with-compile-time-errors --test-mode --allow-mock-compilation --categories=all --minify --use-kernel --strong --packages=/b/swarming/w/ir/.packages /b/swarming/w/ir/out/ReleaseIA32/generated_tests/language_2/type_alias_equality_test_01.dart --out=/b/swarming/w/ir/out/ReleaseIA32/generated_compilations/dart2js-strong-minified-sdk/multitest_language_2_type_alias_equality_test_01/out.js
exit code:
0
stdout:
Compiled 8,847,518 characters Dart to 26,765 characters JavaScript in 0.86 seconds
Dart file (/b/swarming/w/ir/out/ReleaseIA32/generated_tests/language_2/type_alias_equality_test_01.dart) compiled to JavaScript: out/ReleaseIA32/generated_compilations/dart2js-strong-minified-sdk/multitest_language_2_type_alias_equality_test_01/out.js
--- Command "d8" (took 72ms):
DART_CONFIGURATION=ReleaseIA32 /b/swarming/w/ir/third_party/d8/linux/d8 out/ReleaseIA32/dart-sdk/lib/_internal/js_runtime/lib/preambles/d8.js /b/swarming/w/ir/out/ReleaseIA32/generated_compilations/dart2js-strong-minified-sdk/multitest_language_2_type_alias_equality_test_01/out.js
exit code:
1
stdout:
out/ReleaseIA32/dart-sdk/lib/_internal/js_runtime/lib/preambles/d8.js:263: Expect.equals(expected: <aU>, actual: <aV>) fails.
          throw e;
          ^
Expect.equals(expected: <aU>, actual: <aV>) fails.
    at Object.b (/b/swarming/w/ir/out/ReleaseIA32/generated_compilations/dart2js-strong-minified-sdk/multitest_language_2_type_alias_equality_test_01/out.js:303:3)
    at Object.ah (/b/swarming/w/ir/out/ReleaseIA32/generated_compilations/dart2js-strong-minified-sdk/multitest_language_2_type_alias_equality_test_01/out.js:715:24)
    at Object.ai (/b/swarming/w/ir/out/ReleaseIA32/generated_compilations/dart2js-strong-minified-sdk/multitest_language_2_type_alias_equality_test_01/out.js:714:3)
    at a0 (/b/swarming/w/ir/out/ReleaseIA32/generated_compilations/dart2js-strong-minified-sdk/multitest_language_2_type_alias_equality_test_01/out.js:718:17)
    at action (out/ReleaseIA32/dart-sdk/lib/_internal/js_runtime/lib/preambles/d8.js:275:31)
    at eventLoop (out/ReleaseIA32/dart-sdk/lib/_internal/js_runtime/lib/preambles/d8.js:258:9)
    at self.dartMainRunner (out/ReleaseIA32/dart-sdk/lib/_internal/js_runtime/lib/preambles/d8.js:276:5)
    at /b/swarming/w/ir/out/ReleaseIA32/generated_compilations/dart2js-strong-minified-sdk/multitest_language_2_type_alias_equality_test_01/out.js:836:39
    at init.currentScript (/b/swarming/w/ir/out/ReleaseIA32/generated_compilations/dart2js-strong-minified-sdk/multitest_language_2_type_alias_equality_test_01/out.js:832:55)
    at /b/swarming/w/ir/out/ReleaseIA32/generated_compilations/dart2js-strong-minified-sdk/multitest_language_2_type_alias_equality_test_01/out.js:835:84
--- Re-run this test:
python tools/test.py -m release -c dart2js -r d8 -a ia32 --strong --minified --dart2js-with-kernel --use-sdk --output-directory /b/swarming/w/ioVoJYyK --dart2js-batch --reset-browser-configuration language_2/type_alias_equality_test/01
Done dart2js-d8 release_ia32 language_2/type_alias_equality_test/01: fail

The message Expect.equals(expected: <aU>, actual: <aV>) fails seems to imply that the comparison is concerned with type alias names rather than the underlying type.

The failing trybots were dart2js-linux-d8-kernel-minified-try, ddc-linux-release-chrome-try, vm-kernel-mac-release-x64-try, vm-linux-release-x64-try, and vm-mac-release-x64-try (there were some other failures, but they all fail on the test I'm adding in this CL: 'type_alias_equality_test.dart'), so we might need to create a meta bug, or change this to a meta bug, such that we can handle the issue with other tools (e.g., ddc) as well.

[eernstg]

I've written a test for this, added in c98df5b. Status file updates are included in that commit, because several tools fail to pass the test (currently dart2js, dartdevc, fasta, and the vm fail, at least in some configurations). Given that this affects several tools, I've created a new meta-bug #32782 for this, and this issue is henceforth the fasta specific issue for #32782. I updated the initial comment on this issue to to say so. This issue used to have the label Resolution: works as intended, but the test fails as specified in 'language_2_kernel.status', so I removed that label.

[eernstg]

FYI: The language specification has been clarified to specify explicitly that 'Type values obtained from a typedef should represent the underlying type, not the typedef', in 4816b60, line 10506-10508.