Uri library strong mode issue

[chalin]

Execute:

// uri_test.dart
main() => print(new Uri.file('somePath'));

under Dart 2.0.0-dev.8.0 strong mode results in a runtime error:

> dart --strong --checked ./uri_test.dart 
Unhandled exception:
type 'List' is not a subtype of type 'List<int>' of 'canonicalTable' where
  List is from dart:core
  List is from dart:core
  int is from dart:core

#0      _Uri._uriEncode (dart:core-patch/dart:core/uri_patch.dart:34)
#1      _Uri._makePath.<anonymous closure> (dart:core/uri.dart:2099)
#2      MappedListIterable.elementAt (dart:_internal/iterable.dart:413)
#3      ListIterable.join (dart:_internal/iterable.dart:148)
#4      _Uri._makePath (dart:core/uri.dart:2100)
#5      new _Uri (dart:core/uri.dart:1497)
#6      _Uri._makeFileUri (dart:core/uri.dart:1725)
#7      new _Uri.directory (dart:core/uri.dart:1670)
#8      _setWorkingDirectory (dart:_builtin:145)

The cause of the problem seems to be missing generic type parameters on some static const like this from core/uri.dart:

  // Characters allowed in the path as of RFC 3986.
  // RFC 3986 section 3.3.
  // pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
  static const _pathCharTable = const [/*snip*/]; // <=== should be const <int>[...]

This was fixed by 757d806, but that PR seems to have missed two declarations:

• static const _pathCharOrSlashTable
• static const _queryCharTable

which will probably need to be declared as const <int>[...] too.

cc @kwalrath @kevmoo @lrhn @leafpetersen

[chalin]

To give you some context, I ran into this issue when attempting to execute (and write tests for) the server samples in the Write HTTP Clients & Servers tutorial.

[kevmoo]

Thanks, @chalin !

[mraleph]

@chalin --strong is only expected to work when you are running VM with the common front-end. CFE would actually infer int type arguments for those const lists even if you don't specify them.

Compare:

╭─vegorov@volhv ~/src/dart/sdk ‹master›
╰─$ out/ReleaseX64/dart --strong --checked t/b.dart
Unhandled exception:
type 'List' is not a subtype of type 'List<String>' of '_parts@0150898' where
  List is from dart:core
  List is from dart:core
  String is from dart:core

#0      StringBuffer._parts= (dart:core-patch/dart:core/string_buffer_patch.dart:17)
#1      StringBuffer._addPart (dart:core-patch/dart:core/string_buffer_patch.dart:163)
#2      StringBuffer.write (dart:core-patch/dart:core/string_buffer_patch.dart:67)
#3      ListIterable.join (dart:_internal/iterable.dart:154)
#4      _Uri._makePath (dart:core/uri.dart:2100)
#5      new _Uri (dart:core/uri.dart:1497)
#6      _Uri._makeFileUri (dart:core/uri.dart:1725)
#7      new _Uri.directory (dart:core/uri.dart:1670)
#8      _setWorkingDirectory (dart:_builtin:145)
╭─vegorov@volhv ~/src/dart/sdk ‹master›
╰─$ pkg/vm/tool/dart2 t/b.dart
somePath

dart2 is a wrapper script that enables CFE and additional runtime semantics. Unfortunately there is no packaged way to run dart with common front-end from SDK right now.

[chalin]

Unfortunately there is no packaged way to run dart with common front-end from SDK right now.

So, essentially, there is no way to run Dart in strong mode on the VM at the moment?

Could we keep this issue open until there is a way to run dart with the CFE?

[lrhn]

You cannot run existing Dart code with the strong mode type system and no inference. It simply will not work. (I tried too, starting with the <int> on those lists, but it ended up at a function literal that I had no way to write a correct return type for, so it simply could not be fixed at the source level).

To run strong mode on the VM, you need to use the kernel compiler for it, to generate code that has the correct inferred types. There won't be a way to run strong mode directly on the VM, all strong mode code will have to be compiled by the common front-end.

If we need a script to kernel-compile and VM-run strong mode Dart scripts, we should have a separate issue for that.

[chalin]

If we need a script to kernel-compile and VM-run strong mode Dart scripts, we should have a separate issue for that.

Here it is #31544.

[kevmoo]

Couldn't we just fix this by adding the type – to unblock @chalin ?

[lrhn]

Adding the missing <int> is not enough. After that, something else will break. It's a fool's errand to try to make strong mode code run without inference - you get all of the strong type requirements, and none of the tools to satisfy them.

[chalin]

There won't be a way to run strong mode directly on the VM ...

If we can't run strong mode on the VM, it might be a good idea to drop the --strong flag (yes, I know that it is not officially supported, but its presence is none-the-less misleading).

WDYT?

[mraleph]

it might be a good idea to drop the --strong flag

I am going to make --strong without --dfe an error. I just did not get to that yet.

[chalin]

Great, thanks. Here is the issue to track that, #31561, along with the extra request to make --dfe an error until it is actually supported :).