Issues compiling with Dev Sdk

[tensor-programming]

Currently on 2.0.0-dev.67.0 of the sdk.

A few type errors occur when trying to compile an RPC project.

Here are some of the common errors that seem to occur.

Error: A value of type '(dart.core::String, dynamic) → dart.core::Null' can't be assigned to a variable of type '(dynamic, dynamic) → void'.
Try changing the type of the left hand side, or casting the right hand side to '(dynamic, dynamic) → void'.
    (mapObject as Map).forEach((String key, object) {

Error: A value of type '(dart.core::String, dynamic) → dart.core::Null' can't be assigned to a variable of type '(dynamic, dynamic) → void'.
Try changing the type of the left hand side, or casting the right hand side to '(dynamic, dynamic) → void'.
    (encodedMap as Map).forEach((String key, encodedObject) {

Error: A value of type '(dart.core::String, dynamic) → dart.core::Null' can't be assigned to a variable of type '(dynamic, dynamic) → void'.
Try changing the type of the left hand side, or casting the right hand side to '(dynamic, dynamic) → void'.
    (result as Map).forEach((String key, value) {

The getter 'isRegularMethod' isn't defined for the class 'dart.mirrors::DeclarationMirror'.
Try correcting the name to the name of an existing getter, or defining a getter or field named 'isRegularMethod'.
      if (dm is! MethodMirror || !dm.isRegularMethod) {

Seems like most of these errors are a result of the dart strong mode changes for 2.0.

[jcollins-g]

This package in general seems not to be Dart 2 clean -- many analysis warnings and test failures on latest dev SDKs. I'm looking into it since dartpad needs this package to keep working for the latest 2.0 dev SDKs, but someone more familiar with the package might get to it faster (and I'm happy to defer)

[mkustermann]

Assigning to @jcollins-g, since you mentioned you're looking into it.

[enyo]

Is there any update on this? Just ran into this problem, and wanted to know whether I should look into writing a hotfix myself or if a fixed version will be released soon. Thanks!

[jcollins-g]

I am looking at it, but the problem is complex and I have limited time to spend on it, so I can't guarantee an ETA.

[enyo]

Ok thanks. I'll write a patch, and will send you a PR. Maybe you can use that.

EDIT: Current state is here: https://github.com/enyo/rpc/tree/dart-2-beta
Still having some problems when trying to run the generator...

Unhandled exception:
[IsolateSpawnException: Unable to spawn isolate: http://127.0.0.1:50447:1: Error: File http://127.0.0.1:50447 does not exist., #0      Isolate.spawnUri (dart:isolate/runtime/libisolate_patch.dart:450:14)
<asynchronous suspension>
#1      ClientApiGenerator._isolateTrampoline (file:///Volumes/CaseFS/rpc/bin/generate.dart:302:26)
<asynchronous suspension>
#2      _startIsolate.<anonymous closure> (dart:isolate/runtime/libisolate_patch.dart:282:17)
#3      _RawReceivePortImpl._handleMessage (dart:isolate/runtime/libisolate_patch.dart:165:12)
]
#0      ClientApiGenerator.generateDiscovery.<anonymous closure> (file:///Volumes/CaseFS/rpc/bin/generate.dart:202:14)
<asynchronous suspension>
#1      ClientApiGenerator._withServer (file:///Volumes/CaseFS/rpc/bin/generate.dart:292:21)
<asynchronous suspension>
#2      ClientApiGenerator.generateDiscovery (file:///Volumes/CaseFS/rpc/bin/generate.dart:200:12)
<asynchronous suspension>
#3      main (file:///Volumes/CaseFS/rpc/bin/generate.dart:120:35)
<asynchronous suspension>
#4      _startIsolate.<anonymous closure> (dart:isolate/runtime/libisolate_patch.dart:277:32)
#5      _RawReceivePortImpl._handleMessage (dart:isolate/runtime/libisolate_patch.dart:165:12)

Will continue investigating tomorrow.

[jcollins-g]

@enyo I am at or near the same place, though I've been working at it from getting the tests running:
https://github.com/dart-lang/rpc/tree/dart2-rpc

On that branch all the tests now pass that don't depend on spawning the isolate. A fix for dart-lang/sdk#33741 just landed for the SDK so it should be possible shortly to try making those tests run.

[jcollins-g]

Another issue is that the uri package is not dart 2 clean. Filed as google/uri.dart#32

[enyo]

Ok, so basically, we need to wait for the next dart release?

[jcollins-g]

Fortunately it was a short wait. I think .69 has what we need to keep moving, will try to get going on that today.

[jcollins-g]

Many of the things wrong in the tests post .69 have to do with integer math.

In order to continue to allow uint64 as a valid type and to not require BigInts everywhere an integer ApiProperty is declared, I think I can do one of three things:

1. Split uint64 out into a BigInt friendly ApiProperty and require all clients using uint64 to update their ApiProperty metadata.
2. Handle all integers bitwise, allowing things like 0x80000000 for int32 as that's a valid negative number, and similarly for int64.
3. Create inconsistent handling where int64 is handled bitwise, but int32 is not (that's closest to what I ducttaped together in the above mentioned branch just to power through to blockers).

My inclination is to do the first option, as that's the most consistent, only breaks clients who really could be impacted by the math changes, and is least likely to lead to subtle errors downstream. I'm pretty much against #3 but I could be convinced if we really know downstream users rarely care about these distinctions. #2 worries me that users might be depending on these edge cases but seems less dangerous than #3.

@mkustermann, @enyo thoughts?

[enyo]

I’m not sure I understand your proposal nr. 1. Can you elaborate on that?

Other than that, did you get the compiler to run again?

[jcollins-g]

I'm still fleshing out what I'm trying to do with #1 in a branch. Basically, the end result of #1 is if users are doing something with a uint64 type, they have to use BigInts to specify the min/max and values returned, and something will throw if they don't. Exactly how to implement this I'm prototyping as we speak. I think it may be possible to use dynamic for min/max value in ApiProperty and automatically switch out between IntegerProperty and BigIntegerProperty objects, for example, and just do runtime type checking -- when I first wrote the above I thought I might have to fork ApiProperty itself.

Haven't looked at the compiler bit yet, the maze of integer problems in the tests is pretty large and I am motivated to try to address that first since we'll have to eventually anyway. Though the isolate problem is indeed gone.

[jcollins-g]

A lack of constant and literal BigInts is a problem. I have a solution that at least runs and passes tests (require all 64 bit integer ApiProperty annotations to use string-representations), but is silly.

I'm hoping dart-lang/sdk#33893 results in a better option.

[jcollins-g]

The last update to the branch here seems to work (i.e. generator can run and produce something usable) in trivial cases:
https://github.com/dart-lang/rpc/tree/dart2-rpc

This includes the silly 64 bit integers as strings hack, which is actually nicer looking than what I was doing before.

Requires a uri.dart with:
google/uri.dart#33