A few tests related to type aliases should be updated

[chloestefantsova]

I think the following three tests should be updated:

• co19/Language/Generics/Superbounded_types/typedef3_A01_t06/02
B<A<A<A<B<A<dynamic>>>>>> is super-bounded, so the line containing it shouldn't be marked as expecting a compile-time error.
• co19/LanguageFeatures/Instantiate-to-bound/nonfunction_typedef/static/nonfunction_l1_t04
  Seems that the errors are expected; although, the location of one of the three errors is different for Analyzer and the CFE because the CFE can't point inside of types yet. I guess the test should be updated adjusting the locations of the errors.
• co19/Language/Generics/typedef_A06_t04
  The right-hand side of the typedef there is a regular-bounded type (it's not even an application of a generic type to type arguments), and all parts of it are well-bounded.

[iarkh]

Issue 42435 describes exactly the case from * co19/Language/Generics/typedef_A06_t04.

Is is marked as area-front-end and its evaluation reads that there should be a compile error there.

So which behavior is really correct?

[eernstg]

About co19/Language/Generics/typedef_A06_t04:

Reading the error specification again, the error does actually apply for formal type parameters declared by any kind of entity (in particular, it applies for formal type parameters of a function declaration and of a function type). So there is no need to change the specification after all.

The test currently expects a compile-time error, which is correct, but it is somewhat misleading when it says that @description Checks that it is a compile time error if [T] is not well-bounded, because the real error is that a bound without simple bounds can't be raw.

(So A is an error when used as a bound. This can't be a bounds checking issue with Function<X extends A>(), because Function<X extends U>() is regular-bounded for any type U, and it can't be a bounds checking issue with A, because A can be used raw in many other locations, in which case it is a correctly super-bounded type.)

[chloestefantsova]

I found one more test that needs correction: co19/LanguageFeatures/Instantiate-to-bound/nonfunction_typedef/static/nonfunction_l1_t08

The line to be corrected is line 60:

  F<A<C<dynamic>?>> target  = fsource;

As I understood from our conversation with @eernstg it should be marked as a compile-time error in the testcase.

[eernstg]

Just to make sure we can track down reasons & mistakes 😄  here's the reasoning:

A<C<dynamic>?> // is not well-bounded, because

C<dynamic>? <: C<C<dynamic>?> // does not hold, so it's not regular-bounded, and
C<Never>? <: C<C<Never>?> // does not hold, so it's not super-bounded.

But maybe the intention was to declare the following, because i2b of A is A<C<dynamic>>:

F<A<C<dynamic>>> target  = fsource;

[iarkh]

• co19/LanguageFeatures/Instantiate-to-bound/nonfunction_typedef/static/nonfunction_l1_t04
  Seems that the errors are expected; although, the location of one of the three errors is different for Analyzer and the CFE because the CFE can't point inside of types yet. I guess the test should be updated adjusting the locations of the errors.

Indeed, dart and analyzer claims to the same line, but to the different positions.
@eernstg, am I correct that CFE behavior is wrong and I need to file an SDK bug regarding this?

[eernstg]

Running the test locally, I get the impression that it's just a missing @compile-error in the test. I believe the location of the error is ignored when the expected error is unspecified, so it shouldn't actually be about those locations.

[leafpetersen]

Yes, for unspecified errors the location is ignored. So is there an issue with the test, or is this an implementation issue?

[iarkh]

Yes, for unspecified errors the location is ignored. So is there an issue with the test, or is this an implementation issue?

Now the test contains [analyzer] unspecified and [cfe] unspecified tags which looks OK from my point of view (AFAIK exact error position in string is ignored for unspecified errors):

class A<X extends A<X>> {}
typedef B<X extends A<A<X>>> = A<X>;
//        ^
// [analyzer] unspecified
// [cfe] unspecified

main() {
}

If it's so, then:

• co19/Language/Generics/Superbounded_types/typedef3_A01_t06/02 - is fixed
• co19/LanguageFeatures/Instantiate-to-bound/nonfunction_typedef/static/nonfunction_l1_t04 - is OK
• co19/Language/Generics/typedef_A06_t04 - is OK and SDK Issue 42435 should be fixed.

So can I close this bug as fixed?

[eernstg]

As I mentioned, co19/LanguageFeatures/Instantiate-to-bound/nonfunction_typedef/static/nonfunction_l1_t04 succeeds if the line * @compile-error is added. Just tried configuration cfe-strong-linux locally, after editing the test to contain that line:

> git diff # in co19/src
diff --git a/LanguageFeatures/Instantiate-to-bound/nonfunction_typedef/static/nonfunction_l1_t04.dart b/LanguageFeatures/Instantiate-to-bound/nonfunction_typedef/static/nonfunction_l1_t04.dart
index bca265b74..0ef765769 100644
--- a/LanguageFeatures/Instantiate-to-bound/nonfunction_typedef/static/nonfunction_l1_t04.dart
+++ b/LanguageFeatures/Instantiate-to-bound/nonfunction_typedef/static/nonfunction_l1_t04.dart
@@ -44,6 +44,7 @@
  *   [<U1,m ..., Uk,m>].
  * @description Checks that instantiation to bounds works as expected for
  * [class A<X extends A<X>>; typedef B<X extends A<A<X>>> = A<X>].
+ * @compile-error
  * @Issue 42446, 45117
  * @author [email protected]
  */
> cd $SDK
> python tools/test.py -n cfe-strong-linux co19/LanguageFeatures/Instantiate-to-bound/nonfunction_typedef/static/nonfunction_l1_t04
Test configuration:
    cfe-strong-linux(architecture: x64, compiler: fasta, mode: release, runtime: none, system: linux, nnbd: strong)
Suites tested: co19
[00:04 | 100% | +    1 | -    0]

=== All 1 test passed ===

I interpret that to mean that the test must be fixed by adding that line.

[leafpetersen]

@eernstg No, I don't think that should be necessary - it does fix it, but I believe only by papering over the problem.

I believe the problem here is that there are three different locations specified on one line in that test, which I don't think is supported?

//        ^           ^^^      ^
// [analyzer] unspecified
// [cfe] unspecified

@munificent might be able to comment.

If I change this test to:

class A<X extends A<X>> {}
typedef B<X extends A<A<X>>> = A<X>;
//        ^
// [analyzer] unspecified
// [cfe] unspecified

it passes on the CFE.

Note that this test is not being run on the analyzer, because it is explicitly skipped.

[leafpetersen]

Filed dart-lang/sdk#45481 to try to sort out why this and other tests are skipped on the analyzer.

[iarkh]

I believe the problem here is that there are three different locations specified on one line in that test, which I don't think is supported?

Such a change's already checked in at 2 days ago

[iarkh]

I found one more test that needs correction: co19/LanguageFeatures/Instantiate-to-bound/nonfunction_typedef/static/nonfunction_l1_t08

The line to be corrected is line 60:

  F<A<C<dynamic>?>> target  = fsource;

As I understood from our conversation with @eernstg it should be marked as a compile-time error in the testcase.

Dart passes with the line 60 whereas analyzer throws a compile time error.

So which behavior is correct here?

To not to lose this problem I've just filed an issue #45487.

[iarkh]

I found one more test that needs correction: co19/LanguageFeatures/Instantiate-to-bound/nonfunction_typedef/static/nonfunction_l1_t08
The line to be corrected is line 60:

  F<A<C<dynamic>?>> target  = fsource;

As I understood from our conversation with @eernstg it should be marked as a compile-time error in the testcase.

Dart passes with the line 60 whereas analyzer throws a compile time error.

So which behavior is correct here?

To not to lose this problem I've just filed an issue #45487.

The test co19/LanguageFeatures/Instantiate-to-bound/nonfunction_typedef/static/nonfunction_l1_t08 will be fixed in the issue #1049, so I am closing #1029 now.

[eernstg]

@leafpetersen wrote:

No, I don't think that should be necessary - it does fix it, but I believe only by papering over the problem.

Of course! I thought the test runner had to have some special magic requiring @compile-error in order to recognize a compile-time error in a co19/co19_2 test, but the // ^ ^^^ ^ location specification obviously just caused the test runner to decide that this was not a test outcome expectation comment at all.