JavaScript compilers support for `--native-null-assertions` in Dart 3.0

[nshahan]

Regarding the --native-null-assertions flag. It provides non-null assertions on values returned from browser APIs when the dart:html library specifies the API should be non-nullable. For each compiler we should consider if this is enabled by default, and if so can it be disabled?

For DDC this is a question of what flags are supported when you try to run a debug app with package:webdev or flutter web. For dart2js it includes those and what flags are available through dart compile js.

cc @sigmundch @srujzs @mit-mit @itsjustkevin

[nshahan]

cc @jakemac53

[jakemac53]

I would probably have it on by default, with the flag to disable it. And dart2js may choose to disable it by default at certain optimization levels also.

[srujzs]

My preference and summarizing my previous comments:

• If we're running in sound null-safety and SDK version is > 3.0.0, we have it on by default in both compilers to ensure soundness.
• If dart2js specifies O3 or higher, we disable these assertions for performance.

We could have it so that you can't disable it (% optimization flags), but maybe that's too restrictive. The problem, though, is google3 and possibly even Flutter have it disabled by default. We'd want to change that if we're saying you can still disable it. Eventually, we want to remove this flag/option altogether, but that's further in the future.

[nshahan]

@srujzs

• If we're running in sound null-safety and SDK version is > 3.0.0, we have it on by default in both compilers to ensure soundness.
• If dart2js specifies O3 or higher, we disable these assertions for performance.

Does this accurately describe the combination space for these flags that you would like to see?

	--native-null-assertions	--no-native-null-assertions
-o2 and below	no-op (already enabled by default)	disable the native assertions
-o3 and above	no-op (checks get removed at these optimization levels)	no-op (checks are already removed at these optimization levels)

[srujzs]

Yes, but there was the open question of whether we want to ignore --no-native-null-assertions (or even better, warn that this isn't supported > 3.0.0), and still assert except for optimization reasons.

This may prove to be a bigger change to plumb through, and I expect the need to use --no-native-null-assertions will be very low, so I think that table is probably the best idea going forward.

[nshahan]

@jakemac53
What is the status of this flag in the release of build_web_compilers we did for Dart 3.0? On by default with the ability to disable?

[jakemac53]

Correct, it is currently enabled by default and you can disable it in build.yaml (or with a --define flag).

[nshahan]

@srujzs
In a conversation with @sigmundch he said we should investigate allowing the checks to be manually enabled in -o3 and above when you pass the flag. Other options do allow for them the values prescribed by the -o flag to be overridden manually at those levels.

[srujzs]

How can we differentiate that versus a default? If by default, they are enabled, and then the user uses -o3, how can we tell whether --native-null-assertions was a "default yes" versus a "manual yes"?

[jakemac53]

With the args package you can ask if something was actually provided as an argument with wasParsed