mixin application introduces implicit nit/conflict.

[sigmundch]

The way we materialize mixin applications in fasta is generating name conflicts when these types get exported.

This came up in flutter (see #30491 (comment))

We have discussed separately that for some platforms we might want to not share the name of any mixin application by introducing the name of the class where it is applied to as part of the name (e.g. Object&M^for^A or something prettier). I'm guessing the solution here might be similar (e.g. include something in the name that is derived from the library, for example).

Since dart2js also needs to keep all these applications separate (one per class application), I'd be happy directly doing that for now, and later coming back to see if adding sharing helps.

Below are some repro instructions:

repro.dart:

import 'package:front_end/src/testing/compiler_common.dart';
import 'package:front_end/front_end.dart';

main() async {
  var sources = <String, dynamic>{
    'a.dart': 'class A extends Object with M {}  class M {}',
    'b.dart': 'import "a.dart"; class B extends Object with M {}',
    'c.dart': 'export "a.dart"; export "b.dart";',
  };
  await compileUnit(sources.keys.toList(), sources, options: new
      CompilerOptions()..onError = (e) => print('${e.severity}: ${e.message}'));
}

Then run:

DART_CONFIGURATION=ReleaseX64 out/ReleaseX64/dart foo/repro.dart

Produces this nit:

Severity.nit: 'Object&M' is exported from both 'a.dart' and 'b.dart'.

Similarly, if you export "a.dart" in "b.dart" you get a slightly different but related error message.

[peter-ahe-google]

Those shouldn't be exported. Perhaps I should make them private.

[peter-ahe-google]

Proposed fix CL 3004703002.