Static and runtime errors for `main` seem under-specified

[leafpetersen]

There seem to be no static errors specified for the signature provided for main, and the runtime semantics don't seem to make it clear that as a result the invocation needs to do a dynamic type check. In practice, the VM at least seems to do so.
This program:

void main(int x) {
  x.isEven;
}

produces the following runtime error when run:

Unhandled exception:
type 'List<String>' is not a subtype of type 'int' of 'x'
#0      _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:299:32)
#1      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:168:12)

This seems like it needs clarification in the spec, and possibly tests.

[natebosch]

Adding any static error here will be breaking. If we add one it needs to be gated by the language version.

The name main is not (currently) reserved for the entrypoint method. You can define main in any library and invoke it with any arguments.

I'm not opposed to it, but we should be aware that we are enforcing a (quite reasonable) convention by adding static checking to the signature of functions named main.

[leafpetersen]

The name main is not (currently) reserved for the entrypoint method. You can define main in any library and invoke it with any arguments.

That's not quite true (at least per spec). The restrictions are small, but as I understand the spec (quoted below):

• Any symbol named "main" is treated as an entry point
• It is a compile time error if that symbol is a non-function, and has more than two positional parameters
• That symbol will be invoked according to a specific procedure.

It's just that the spec above is not restrictive enough to be sound.

A script $S$ is executed as follows:

\LMHash{}%
First, $S$ is compiled as a library as specified above.
Then, the top-level function defined by \code{main}
in the exported namespace of $S$ is invoked (\ref{functionInvocation})
as follows:
If \code{main} can be called with with two positional arguments,
it is invoked with the following two actual arguments:
\begin{enumerate}
\item An object whose run-time type implements \code{List<String>}.
\item An object specified when the current isolate $i$ was created,
for example through the invocation of \code{Isolate.spawnUri} that spawned $i$,
or the null object (\ref{null}) if no such object was supplied.
\end{enumerate}
If \code{main} cannot be called with two positional arguments,
but it can be called with one positional argument,
it is invoked with an object whose run-time type implements \code{List<String>}
as the only argument.
If \code{main} cannot be called with one or two positional arguments,
it is invoked with no arguments.

\commentary{
Note that if \code{main} requires more than two positional arguments,
the library is not considered a script.
}

\commentary{
A Dart program will typically be executed by executing a script.
}

\LMHash{}%
It is a compile-time error if a library's export scope contains a declaration
named \code{main}, and the library is not a script.
\commentary{This restriction ensures that all top-level \code{main} declarations
introduce a script main-function, so there cannot be a top-level getter or field
named \code{main}, nor can it be a function that requires more than two
arguments. The restriction allows tools to fail early on invalid \code{main}
methods, without needing to know whether a library will be used as the entry
point of a Dart program. It is possible that this restriction will be removed
in the future.}

[natebosch]

That's not quite true (at least per spec)

Maybe I misunderstood the scope of this issue? If "static error" means "error reported by a backend" and not "error reported by the analyzer or CFE" then I don't have any concerns.

[leafpetersen]

Maybe I misunderstood the scope of this issue? If "static error" means "error reported by a backend" and not "error reported by the analyzer or CFE" then I don't have any concerns.

No, it means the latter. Runtime error means the former. I believe that the spec above implies that this program is a static (CFE/analyzer) error:

void main(int x, int y, int z) {
  x.isEven;
}

No such error is, in fact reported. So the implementations are missing some specified static errors. I also believe that the above text does not imply that the original program should have a runtime error. But the implementations do in fact report one. Consequently, the implementations are also implementing additional runtime checks beyond what are specified (fortunately).

Both of the above issues should be resolved. Agreed that if we resolve them by adding compile time errors then it is a breaking change which needs to be guarded by a language version.

[natebosch]

The spec quote refers to A script $S$ is executed as follows: and I understand it to be limited to rules for the libraries that are executed. It does not apply to all libraries.

As per my understanding of the spec (and the behavior of existing tools) the following is a valid Dart library:

void main(int x, int y, int x) => x.isEven;

And here is a valid script that can be executed:

import 'that_other_file.dart' as other;

void main() {
  print(other.main(1,2,3));
}

[leafpetersen]

@natebosch I can't reconcile with what you are saying with the two pieces quoted below. The first is commentary and not normative, so it's possible that it's incorrect, but assuming not, I don't see any way to read these as saying anything other than that: "if you have a declaration named main and you are not a script it's a compile time error" (this is normative) and "if you have main with more than two positional arguments you're not a script" (this is commentary). If the latter is correct, then the former implies your first example is specified to be compile time error.

\commentary{
Note that if \code{main} requires more than two positional arguments,
the library is not considered a script.
}

It is a compile-time error if a library's export scope contains a declaration
named \code{main}, and the library is not a script.

[natebosch]

Ah, I missed the second part there.

It is a compile-time error if a library's export scope contains a declaration
named \code{main}, and the library is not a script.

Neither the CFE nor analyzer has ever enforced this as far as I can tell. I would bet that there is code that would be broken if we started enforcing it. Null safety might be a good point to start enforcing it, though it could force breaking changes onto folks that migrate.

[lrhn]

The rule was introduced at the request of Peter because modular compilation cannot know whether a file is used as a script or not, and the parser output needed a way to designate the main method of a library, and whether it is valid or not. I don't remember the exact details of why things had to be this way, it was probably for historical reasons, but after some discussion we ended up with the current specification. Maybe it was just because it meant that you couldn't give a good error message if someone wrote a wrong main, because you couldn't know whether it was going to be used as an entry point or not.
Maybe @eernstg remembers more?

I had assumed that Fasta would implement the spec. (Could it be that the error is recorded in the parser output, but that is ignored by later steps?).

What I would personally prefer is a compile-time error if an entry point library does not export a function declaration with a signature assignable to one of void Function(), void Function(List<String>) or void Function(List<String>, Object?).
We could be lenient and dynamic and allow void Function(List<String>, Never) for the last one, so that you can type the object that you send with Isolate.spawnUri as what it is (and fail dynamically if it isn't, but if the alternative is an immediate value as ExpectedType, then it's going to fail anyway).

[natebosch]

What I would personally prefer is a compile-time error if an entry point library does not export a function declaration with a signature assignable to one of void Function(), void Function(List<String>) or void Function(List<String>, Object?).

Our web compilers will never pass "real" arguments through. Should we consider allowing the web compilers to make it an error to use a function that isn't assignable to void Function() and disallow the others?

cc @sigmundch @rakudrama

[rakudrama]

Some customers use dart2js code from node.js, so we should not break them by prohibiting passing parameters to main.

I know Sass uses dart2js in this way. They have an primary entry point (main) which takes an argument and works from the VM, and a second main with no arguments which wraps the primary main with js-interop to export the primary main as a method of an npm module. This method is called many times by the node.js build app in which the Dart app is embedded.

Unminified output from dart2js has had this comment for many years, so who knows how many other user do something similar:

// The code supports the following hooks:
...
// dartMainRunner(main, args):
//    if this function is defined, the Dart [main] method will not be invoked
//    directly. Instead, a closure that will invoke [main], and its arguments
//    [args] is passed to [dartMainRunner].

It is very difficult for JavaScript app to call the entry point correctly since it is an internal detail of the Dart app as to what exactly will pass as a List<String>. Sass exports a closure similar to this:

allowInterop((dynamic args) => primary.main(List<String>.from(args as List<dynamic>)));

This works because Sass is called with the obvious JavaScript Array and DDC and dart2js recognize a JavaScript Array as a List<dynamic>.

I propose:

• Web compilers permit all specified versions of main.
• For main(), nothing extra needs to be done, so there is no impact in web apps.
• For other forms of main, web compilers inject code into main before any checks to 'upgrade' the first input to a valid List<String>. We don't have to call List.from, and I think it would be reasonable to take the short-cut of assuming the elements of the Array are strings.

For example, dart2js might inject this code into main:

if (args == null) args = [];
if (Array.isArray(args)) args = H.setArrayType(Array.prototype.slice.call(array), type$.JSArray_String);

This would handle an inadvertent null or undefined and not drag in any code that is not already present in non-trivial apps.

[leafpetersen]

@rakudrama my initial though was just to specify that main is invoked dynamically (hence, you can put whatever the hell you want on it as the type annotations, and so long as a dynamic call to it with whatever the compiler chooses to pass in works, you're good). Does that not have the properties you want?

[natebosch]

Some customers use dart2js code from node.js, so we should not break them by prohibiting passing parameters to main.

Does dart2js support that today? When you compile with dart2js for node and use the node preamble, does it support passing arguments through?

They have an primary entry point (main) which takes an argument and works from the VM, and a second main with no arguments which wraps the primary main with js-interop to export the primary main as a method of an npm module.

As long as we only enforce this restriction on the entrypoint which is used this won't affect that use case. Whatever decision we make on restrictions around top-level symbols named main I would propose that additional restrictions imposed by the web compilers would not apply to all main, and would only apply to to the one that is used.

• For other forms of main, web compilers inject code into main before any checks to 'upgrade' the first input to a valid List<String>. We don't have to call List.from, and I think it would be reasonable to take the short-cut of assuming the elements of the Array are strings.

I don't understand this. What is the purpose of having a compiler hardcoded to always pass an empty list? As a user I would strongly prefer if it was made statically clear to me that I will never get a "real" value to my main from the compiler than if I was just given an empty list no matter what.