Augment output in dart compile to clarify null safety compilation mode

[vsmenon]

I got confused when retrying a migration. I'd accidently left a @dart = 2.10 in my entry point but migrated the rest of the app and the pubspec.

Might be worth emitting a warning that the mode disagrees with the pubspec.

Also not sure if this is best done in CFE or flutter tool - @mit-mit @johnniwinther @jonahwilliams

[johnniwinther]

The CFE never reads the pubspec.yaml. Only the package_config.json (through package:package_config).

[jonahwilliams]

Should this be a warning? Maybe the AI is to make it more obvious what mode we're running in?

[johnniwinther]

@mit-mit What are your thoughts on this?

[mit-mit]

From a discussion in the language team, we think this should not be a warning shown when running dart code (e.g. running dart bin/main.dart; that is potentially breaking. We also don't think it should be shown during analysis, as that could easily get annoying (the developer opts out, and is then immediately hit with warning).

But, we still think it's worth adjusting the output of commands that build release-mode artifacts to state which form of null safety was used. Concretely we'd like to suggest we adjust the output of dart compile and flutter build, so that when the SDK constraint is 2.12 or above, we add output like this:

$ dart compile exe bin/myapp.dart
Compiled exe with sound|sound null safety: /Users/mit/tmp/myapp/bin/myapp.exe

$ flutter build apk
Compiling Dart code with sound|unsound null safety.
Running Gradle task 'assembleRelease'... Done                     113.6s
✓ Built build/app/outputs/flutter-apk/app-release.apk (15.4MB).

WDYT @jonahwilliams @bkonyi @devoncarew ?

[devoncarew]

Consider highlighting the unsound version:

Compiling Dart code with sound null safety.

vs.

Compiling Dart code with unsound null safety.

[devoncarew]

Or even:

Compiling Dart code with unsound null safety (see dart.dev/... for more information).

[bkonyi]

I'm fairly certain I saw flutter run output a message about running with unsound null safety last week. We should have a way for users to check whether or not they're running with sound/unsound null safety even when running against the JIT (maybe add a new flag or put it behind the --verbose option?). In general though, I'm supportive of adding this as output for commands that generate artifacts.

[zanderso]

The proposal in #44234 (comment) makes sense to me. Please file an issue in the Flutter issue tracker for the work needed on the Flutter tool. Thanks!

[mit-mit]

Thanks @zanderso, opened flutter/flutter#72279 for the warning in flutter build

[mit-mit]

Updating the present issue to track the change in dart compile:

$ dart compile exe bin/myapp.dart
Compiled exe with sound|sound null safety: /Users/mit/tmp/myapp/bin/myapp.exe