[ddc] Application of generic mixins before definition throws error in `makeGenericType`

[dnys1]

This issue seems related to #34244, although I couldn't say for sure if it's the same. The following code will crash in DDC depending on the ordering of the statements:

class C<T extends B> with A<C> {}

abstract class B with A<B> {}

mixin A<T> {}

void main() {}

Error

$ tool/ddb test/module_order_test.dart 
Debugger listening on ws://localhost:9222/3aeaf8e3-e5e7-44f7-bb2a-961d61e1d619
Debugger listening on ws://localhost:9222/3aeaf8e3-e5e7-44f7-bb2a-961d61e1d619
For help, see: https://nodejs.org/en/docs/inspector
/Users/nydillon/dev/dart-sdk/sdk/xcodebuild/ReleaseX64/gen/utils/dartdevc/kernel/common/dart_sdk.js:6445
  throw Error(message);
  ^

Error: type arguments should not be null: T => {
  const Object_A$36 = class Object_A extends core.Object {};
  (Object_A$36.new = function() {
  }).prototype = Object_A$36.prototype;
  class C extends Object_A$36 {
    static ['_#new#tearOff'](T) {
      return new (module_order_test.C$(T)).new();
    }
  }
  (C.new = function() {
    ;
  }).prototype = C.prototype;
  dart.addTypeTests(C);
  C.prototype[_is_C_default] = true;
  dart.addTypeCaches(C);
  dart.setLibraryUri(C, I[0]);
  return C;
}
    at Object.throwInternalError (/Users/nydillon/dev/dart-sdk/sdk/xcodebuild/ReleaseX64/gen/utils/dartdevc/kernel/common/dart_sdk.js:6445:9)
    at Object.makeGenericType [as C$] (/Users/nydillon/dev/dart-sdk/sdk/xcodebuild/ReleaseX64/gen/utils/dartdevc/kernel/common/dart_sdk.js:4604:14)
    at /Users/nydillon/dev/dart-sdk/sdk/pkg/dev_compiler/test/module_order_test.js:47:93
    at Object.makeGenericType [as C$] (/Users/nydillon/dev/dart-sdk/sdk/xcodebuild/ReleaseX64/gen/utils/dartdevc/kernel/common/dart_sdk.js:4616:50)
    at Object.<anonymous> (/Users/nydillon/dev/dart-sdk/sdk/pkg/dev_compiler/test/module_order_test.js:49:41)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/Users/nydillon/dev/dart-sdk/sdk/pkg/dev_compiler/test/module_order_test.run.js:10:12)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47

Of note, the following variation compiles and runs successfully (declaring the classes in order of use):

mixin A<T> {}

abstract class B with A<B> {}

class C<T extends B> with A<C> {}

void main() {}

And even simply declaring B before C seems to work:

abstract class B with A<B> {}

class C<T extends B> with A<C> {}

mixin A<T> {}

void main() {}

The issue is reproducible for me on master and stable:

master version:

$ dart --version
Dart SDK version: 2.19.0-edge.5cc2856daa9f62245ef0aaddd966321fcb0310ea (be) (Tue Jul 19 00:03:04 2022 +0000) on "macos_x64"

stable version:

$ dart --version
Dart SDK version: 2.17.6 (stable) (Tue Jul 12 12:54:37 2022 +0200) on "macos_x64"

In the package where this was discovered, the re-ordering of declarations above is simply not possible or too involved given all the dependencies.

[srujzs]

cc @nshahan

[nshahan]

@dnys1 Thanks for the simple reproduction. It looks like the code ordering algorithm in DDC still has issues with some patterns related to mixins.

[Pacane]

cc: @kevmoo we faced this issue a few weeks ago. IIRC we worked around it using something like this, which suggests something like changing the type of import.

I also believe we could have re-ordered the members in a file like shown in this issue, but I think our use case was caused by classes in different files/packages.

[nshahan]

This ordering issue is avoided in the new runtime type system (DDC canary mode) because the types are no longer linked to the class code. It will be fixed in stable once that feature graduates to stable mode.