Errors don't inform the user of --no-sound-null-safety

[mit-mit]

Porting flutter/flutter#70145 by @tvolkert:

---

Steps to reproduce:

1. Upgrade your app to null safety
2. Introduce a package dependency for which the package has no null safe version
3. Run flutter run

Expected results

You expect the error message to tell you both why it's unable to run in sound mode (because the dependencies aren't null safe) and how to get around the error (by running with --no-sound-null-safety).

Actual results

It tells you why it failed to build and how to inspect the package versions, but it doesn't tell you how to sidestep the problem for now...

> flutter run -t lib/main.dart -d iphone --debug
Running "flutter pub get" in payouts...                            458ms
Launching lib/main.dart on iPhone 11 Pro Max in debug mode...
Running pod install...                                           1,746ms
Running Xcode build...                                                  
Xcode build done.                                           15.6s
Failed to build iOS app
Error output from Xcode build:
↳
    ** BUILD FAILED **


Xcode's output:
↳
    Error: This project cannot run with sound null safety, because one or more project dependencies do not
    support null safety:

     - package:http
     - package:intl
     - package:http_parser

    Run 'pub outdated --mode=null-safety' to determine if versions of your
    dependencies supporting null safety are available.

    Command PhaseScriptExecution failed with a nonzero exit code
    note: Using new build system
    note: Planning build
    note: Constructing build description

Could not build the application for the simulator.
Error launching application on iPhone 11 Pro Max.

Sure enough, in this example, running flutter run --no-sound-null-safety ... allowed the app to run.

[mit-mit]

@jonahwilliams comments:

For both the CFE and flutter, the correct flag in this case is --no-sound-null-safety, so the CFE error messages could be updated to vaguely reference "running" with that flag and still be correct for both flutter and Dart.

Alternatively, the compiler could return a specific error code that the tool could interpret to add an additional footer with more context.

The tool could also try and parse the stdout, but I think that would be very fragile - given that the message output by CFE may need to evolve anyway and that would make many changes to it breaking.

[mit-mit]

Dart repro steps:

dart create repro
cd repro
dart migrate --apply-changes

Edit pubspec.yaml to have markdown: under deps.

Edit bin/repro.dart to have:

import 'package:markdown/markdown.dart' as m;
final e = m.Element.empty('foo');

Run:

$ dart run
Error: This project cannot run with sound null safety, because one or more project dependencies do not
support null safety:

 - package:markdown
 - package:charcode
 - package:meta

Run 'pub outdated --mode=null-safety' to determine if versions of your
dependencies supporting null safety are available.

[mit-mit]

@johnniwinther I seem to recall that we used to print out this flag, but decided (perhaps ever at my request?) to remove it? Do you recall the history here?

[johnniwinther]

I don't recall having considered mentioning --no-sound-null-safety in the message. We could easily add it, though. It's just a question of what the best wording is.

[mit-mit]

Stay tuned; we'll discuss in the language meeting later today.

[mit-mit]

Discussed in language team meeting. We like to not put the concrete fix in the tool output itself (as there are several ways to resolve this; the flag --no-sound-null-safety is just one option, another one is @Dart language markers).

Rather, we'd like the output to print a link:

$ dart run
Error: This project cannot run with sound null safety, because one or more project dependencies do not
support null safety:

 - package:markdown
 - package:charcode
 - package:meta

Please see https://dart.dev/go/no-sound-null-safety for solutions to this.

@munificent can then work with @kwalrath on content for that page (this can be based on our current "mixed mode" content). Bob & Kathy, can you please review my output above?

[munificent]

I would remove "possible" since there definitely are solutions, but otherwise that wording looks good to me.

[mit-mit]

Updated!

[kwalrath]

I'd abbreviate "do not", remove "please", and reorder the last sentence. Also, is it true that the list includes all the (direct?) dependencies that don't support null safety? If so, we could be clearer about that. Maybe something like this:

$ dart run
Error: This project cannot run with sound null safety, because the following project dependencies don't
support null safety:

 - package:markdown
 - package:charcode
 - package:meta

For solutions, see https://dart.dev/go/no-sound-null-safety.

So... It sounds like the mixed-mode info (whatever we call it) should go on its own page? I'm fine with that. Sounds like it should point to the main null safety and migration pages, talk about the SDK constraint for opting in, what unsound null safety means, how to use --no-sound-null-safety, ... anything else?

[kwalrath]

Should it be go/no-sound-null-safety or go/unsound-null-safety?

[munificent]

It sounds like the mixed-mode info (whatever we call it) should go on its own page? I'm fine with that.

Looks like we're leaning in that direction, yes. Though arguably it would make more sense to keep the expository information about mixed-mode in an existing page and have this new page just be "you got this scary error message, here's how to fix it".