Skip to content

CFE confuses library prefix and a name of a field #32200

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mraleph opened this issue Feb 16, 2018 · 4 comments
Closed

CFE confuses library prefix and a name of a field #32200

mraleph opened this issue Feb 16, 2018 · 4 comments
Assignees
Labels
customer-flutter legacy-area-front-end Legacy: Use area-dart-model instead. P0 A serious issue requiring immediate resolution

Comments

@mraleph
Copy link
Member

mraleph commented Feb 16, 2018

import 'dart:core' as core;

class Foo {
  core.int core = 10;
}

void main() {
  new Foo();
}
pkg/front_end/tool/fasta compile -o /tmp/xxx.dill --strong-mode --platform=$HOME/src/dart/sdk/out/ReleaseX64/vm_platform_strong.dill /tmp/xxx.dart
Unhandled exception:
Crash when compiling file:///tmp/xxx.dart,
at character offset null:
file:///tmp/xxx.dart:5:3: Internal problem: Unsupported operation: 'name'.
  core.int core = 10;
  ^
#0      internalProblem (package:front_end/src/fasta/problems.dart:29:3)
#1      unsupported (package:front_end/src/fasta/problems.dart:55:10)
#2      IncompleteSend&ErrorAccessor.name (package:front_end/src/fasta/kernel/fasta_accessors.dart:266:20)
#3      IncompleteSend&ErrorAccessor.plainNameForRead (package:front_end/src/fasta/kernel/fasta_accessors.dart:269:34)
#4      getNodeName (package:front_end/src/fasta/kernel/body_builder.dart:4186:17)
#5      BodyBuilder.handleType (package:front_end/src/fasta/kernel/body_builder.dart:1860:40)
#6      Parser.parseType.commitType (package:front_end/src/fasta/parser/parser.dart:2424:18)
#7      Parser.parseType (package:front_end/src/fasta/parser/parser.dart:2499:26)
#8      Parser.parseFields (package:front_end/src/fasta/parser/parser.dart:3136:7)
#9      Parser.parseClassMemberImpl (package:front_end/src/fasta/parser/parser.dart:3800:15)
#10     Parser.parseClassMember (package:front_end/src/fasta/parser/parser.dart:3639:12)
#11     DietListener.parseFields (package:front_end/src/fasta/source/diet_listener.dart:734:22)
#12     DietListener.buildFields (package:front_end/src/fasta/source/diet_listener.dart:579:5)
#13     DietListener.endFields (package:front_end/src/fasta/source/diet_listener.dart:226:5)
#14     Parser.parseFields (package:front_end/src/fasta/parser/parser.dart:3163:16)
#15     Parser.parseClassMemberImpl (package:front_end/src/fasta/parser/parser.dart:3800:15)
#16     Parser.parseClassBody (package:front_end/src/fasta/parser/parser.dart:3615:15)
#17     Parser.parseClass (package:front_end/src/fasta/parser/parser.dart:1732:13)
#18     Parser.parseClassOrNamedMixinApplication (package:front_end/src/fasta/parser/parser.dart:1692:14)
#19     Parser.parseTopLevelKeywordDeclaration (package:front_end/src/fasta/parser/parser.dart:526:14)
#20     Parser.parseTopLevelDeclarationImpl (package:front_end/src/fasta/parser/parser.dart:442:14)
#21     Parser.parseUnit (package:front_end/src/fasta/parser/parser.dart:326:15)
@mraleph mraleph added P0 A serious issue requiring immediate resolution customer-flutter legacy-area-front-end Legacy: Use area-dart-model instead. labels Feb 16, 2018
@peter-ahe-google
Copy link
Contributor

Proposed fix.

@peter-ahe-google
Copy link
Contributor

FWIW, the front-end is not confusing prefix and field name. But it's crashing as it's attempting to report an error.

@vsmenon
Copy link
Member

vsmenon commented Feb 20, 2018

@lrhn Can you clarify if the code at the top is a static error? If so, we should file an issue on the analyzer to report it. We're seeing the pattern in existing user code.

@lrhn
Copy link
Member

lrhn commented Feb 20, 2018

@leafpetersen

I'd say that it is a static error in Dart 2. The core in core.int is resolved in a scope where core is a field. That is consistent with Dart having only one lexical scope.
That's also apparently what implementations do in many places, just not all. Some happen to accept core.int as a malformed type that is interpreted as dynamic.

If we change to:

import 'dart:core' as core;
class Foo {
  core.int core() => 10;
}
void main() {
  core.print(new Foo().core.runtimeType);
}

then dart2js prints () => dynamic and the VM prints () => int. So, no agreement.

If we change the code to:

import 'dart:core' as core;

class Foo {
  get core => <core.int>[];  // Returns List<dynamic> or List<int>?
  get core2 => core.int;  // Stack overflow or return Type?
}

void main() {
  core.print(new Foo().core is core.List<core.String>);
  core.print(new Foo().core2);
}

I would like the two getter bodies to treat core.int the same. Currently both dart2js and the VM treats <core.int>[] as a malformed type, and core.int as a getter access. So, not consistent with treating core.int as a type outside the body.

You say that existing code is using this pattern. Any references?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
customer-flutter legacy-area-front-end Legacy: Use area-dart-model instead. P0 A serious issue requiring immediate resolution
Projects
None yet
Development

No branches or pull requests

4 participants