[dart2js] Runtime error if function 'main' has one or more than two optional positional arguments

[sgrekhov]

With recent change in NNBD specification it is allowed to have one optional positional parameter of main() or more than two optional positional arguments. So, the following is not an error

main([List<String> args = const []]) {
}

main([List<String> args = const [], var i, String s = ""]) {
}

But now, it is a runtime error on dart2js in both of the cases above

[fishythefish]

1. I'm able to compile and run that code successfully, and I'm not seeing any runtime errors.
2. The specification does not say that the above code must be permitted. It does not require that we produce an error, but implementations are free to impose additional restrictions on the signature of main.
3. I believe @rakudrama is implementing a shim to correctly forward arguments to main in JS, so he might have additional thoughts here.

[eernstg]

Some older versions of dart2js incur a run-time error (a crash, arguably) with main([List<String> args = const []]), including 2.11.0-161.0.dev. But a fresh dart2js from 238b7f4 compiles it into code that runs with no errors. This holds for the other example as well.

dart2js can indeed enforce extra restrictions on the signature of main, e.g., such that T main([List<String> args = c]) is a compile-time error for all types T and constants c.

However, given that it is working now, we may wish to keep it that way. The intention behind those extra restrictions was that it would allow us to avoid an implementation effort to support different kinds of main that haven't been supported previously. Another purpose was to get better performance (time or space), or to avoid confusion (cf. @rakudrama's shim: it is confusing if there is a declared parameter args, but command line arguments passed to a compiled dart2js are dropped and [] is passed). But if void main([List<String> args = const []]) should be an error then arguably void main(List<String> args) should also be an error, if the justification is the confusingly missing arguments.

[rakudrama]

The intention is that a future dart2js will accept exactly three signatures for the main function that is used as an entry point:

void main()
void main(List<String> args)
void main(List<String> args, Object? context)

The limitations are because outside values need to be converted before being passed to main. It is not clear how to convert an arbitrary value, or how to detect a missing value.

• Web apps will use main() and incur no cost.
• Script invocations like d8 and nodejs will be able to pass a JavaScript Array of Strings which will be converted into a Dart List<String>.

There is no code yet in preparation to handle a second argument, but it is intended for use with workers. The value will be passed without conversion and may appear in the Dart program to be a value of an external or JavaScript type. The application will be responsible for handling any conversion.

Optional arguments with defaults require a full implementation of dynamic invocation from outside of the program, so will not be supported.

The missing piece of the puzzle is that DDC needs to enforce the same constraints on the entry function without constraining other top-level functions called main. Since DDC uses separate compilation, it does not know if a given main is the entry point. I think this will be solved by marking each main with an indicator of which of the three permitted signatures it implements.

[eernstg]

@rakudrama, thanks for the clarification! The constraints on the signature of main that are covered by this sentence:

Implementations are free to impose any additional restrictions on the
signature of main

are clearly implementation specific. This means that it will not be possible to determine the exact set of main signatures that an implementation must accept. But we have an upper bound (anything that satisfies the general requirements listed in the specification), and each implementation may reject some of these main signatures.

Tests that are failing for this reason should then be disabled for that implementation. Presumably, we can mark them as SkipByDesign in the relevant status file. With that, I believe we can close this issue. I created dart-lang/co19#952 in order to serve as a point of reference in co19 tests.