Sdk: What are the different "configuration modes" for Dart2?

[matanlurey]

_Dev/Prod/Release/Strong/Checked/Asserts OH MY_

Our customers (including folks that are really _in_ the Dartiverse, including even @sethladd) are easily confused on Dart2's different "operating modes" (this is slightly compounded by Flutter having additional "modes").

In Dart1, there was:

• Normal (?) mode (No asserts, which included type annotation checks)
• Web clients had a production mode, i.e. Dart2JS
  
  
  
  • ... which itself had production flags (--minify, and later, --trust-XXX)
  
  

In Dart2, we have:

• Normal (strong) mode (No asserts, but _yes_ on type annotation/type checks)
• Web clients have a dev mode (DDC), a production mode (Dart2JS)
  
  
  
  • ... in which Dart2JS has production flags (--minify, ...)
  
  
• To enable assertions in the (VM only?) you use --enable-asserts
  
  
  
  • ... which is literally just assert(), differing from Dart1.
  
  
• And probably N other modes (profile mode, slow mode) in Flutter.

---

A couple open questions:

1. Can we pick some terminology and stick with it? I.e. "debug" and "release".*
2. Can we have some user-facing docs on the differences between the two?
   b. And the differences between these and Dart1's different modes

_*Just as an idea. Feel free to choose other names._

[sethladd]

Just context here: I was confused, I mistakenly assumed that --enable-assets was turning on "const asserts", which I thought was already on with --preview-dart-2. @matanlurey kindly corrected me. (this was all from a thread on Twitter)

[matanlurey]

Not blaming you, I just mean if _you_ don't know, probably _lots_ others don't either 😨

[yjbanov]

I imagine there are legitimate reasons for having options that are not exposed to users, for the purposes of debugging the VM itself. But I agree that only a few very clear options should be surfaced to the users. FWIW, Flutter tools expose the following options to users:

• debug - assertions, type checks, debugger, observatory - use it to debug _correctness_
• profile - no assertions, no type checks, no debugger, observatory still enabled - use it to debug _performance_
• release - no assertions, no type checks, no debugger, no observatory - use it to deploy your app to _production_

--preview-dart-2 is an internal hidden temporary option. It will go away when Dart 2 is the only mode.

[matanlurey]

@yjbanov:

release - no assertions, no type checks, no debugger, no observatory

FWIW, with --preview-dart-2, this is no longer true. Or you can just play the mental game of "Dart 1 had type checks [dynamic dispatch]", and "Dart 2 moves the type checks to compile-time where possible".

Though maybe someone from the compilers team has a better way of explaining this.

/cc @mraleph

[yjbanov]

Yeah, with Dart 2 type checks are ingested into the new type system and the runtime type checks it comes with (in all modes). So once we are firmly in Dart 2, the "type checks"/"no type checks" distinction will be gone from our options. Which is great! Less is more!

[dgrove]

@anders-sandholm Can you please take a look?

[anders-sandholm]

Seems like this is a tools issue more so than a language issue. That said, @lrhn @leafpetersen, please help clarify if there are things that are unclear in terms of the language definition for these flags?

There is an issue in deciding what flags we want to expose and explain in our Flutter tool chain and Web tool chain. And ideally in making sure they are the same where possible.

@kevmoo @sigmundch @vsmenon -- What is / would be a short, agreed upon list of flags that we want to expose to our web users (across dart2js and DDC)? If we don't have such a list already, could you agree with and implement the ones that Flutter is already using (debug, profile, and release)?

@kmillikin FYI for FE and @a-siva FYI for the VM flags.

[kevmoo]

I opened https://github.com/dart-lang/sdk/issues/32646 to track --checked in the VM CLI

[sigmundch]

we could use similar flags, but I'd be afraid of conflating flags if they have different meaning in flutter and web.

We haven't finalized this, but we have been talking about having 3 common modes in dart2js as well:

• normal (no flags): dart2js in 2.0 mode, includes checks for implicit downcasts and everything that strong-mode does, no assertions.
• debug? (flag: --enable-asserts): to turn on assertions
• production (flag: TBD, e.g. could be --production or --omit-checks): remove implicit downcast checks and parameter checks that would have been omitted with --trust-type-annotations, and similarly may omit range checks and null checks on primitives (like --trust-primitives).

[kevmoo]

I'd like to keep some uniformity w/ the VM.

--enable-asserts for dart2js and VM

The notion of other optimization in dart2js should be orthogonal IMHO

[jmesserly]

I opened a bug for a flag to enable/disable assertions in DDC: https://github.com/dart-lang/sdk/issues/32649

[yjbanov]

What's the value in having the "normal" vs "production" distinction? The reason we have "profile" vs "release" in Flutter is because the two have similar performance characteristics and so "profile" is useful for testing performance.

[jmesserly]

What's the value in having the "normal" vs "production" distinction?

I'm not @sigmundch but here's my take :)

Having a "normal" dart2js mode that implements all required type checks by Dart 2 lets us test it against dartdevc and Dart other implementations. It also gives users a whole program compiler (w/ global type inference, tree shaking) that implements Dart 2 for the web.

"production" is used when teams need the smallest possible code size and fastest possible performance, and are willing to tolerate unsound behavior/optimizations ("going off the rails" types of crashes/data corruption).

[kevmoo]

What Jenny said...

On Thu, Mar 22, 2018 at 3:52 PM Jenny Messerly [e-mail]
wrote:

What's the value in having the "normal" vs "production" distinction?

I'm not @sigmundch https://github.com/sigmundch but here's my take :)

Having a "normal" dart2js mode that implements all required type checks by
Dart 2 lets us test it against dartdevc and Dart other implementations. It
also gives users a whole program compiler (w/ global type inference, tree
shaking) that implements Dart 2 for the web.

"production" is used when teams need the smallest possible code size and
fastest possible performance, and are willing to tolerate unsound
behavior/optimizations ("going off the rails" types of crashes/data
corruption).

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/dart-lang/sdk/issues/32442#issuecomment-375483254,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABCil7swF_m9n6jG9sxcy4hNybZG4neks5thCsVgaJpZM4SfrZy
.

[yjbanov]

Got it, although I personally don't think the distinction is strong enough to warrant a top-level user-facing mode. Maybe a command-line option? Do you expect the users of dart4web to use it or the Dart team? Wouldn't users mostly use DDC, which, I assume, comes with all the same type checks and debugging facilities?

I'm obviously biased, but I think Flutter's build modes would make more sense in the web context too. For example, in a "profile" mode I'd like to see unobfuscated symbols so I can debug memory leaks and understand JS performance profiles, even if the code is tree-shaken, inlined, and otherwise optimized, so its performance resembles that of a production build. I would not expect the debugger to work in a profile mode.

That said, Flutter Dashboard app still runs on Dart 1 (yes, we still use Dartium! 😄), so I'm not speaking from real experience. But I doubt that comparing different Dart implementations would be at the top of my todo list when building a web app.

[jmesserly]

I don't think we need to do anything else in DDC (now that we have --enable-asserts). Feel free to re-tag area-dev-compiler if that assumption is incorrect.

[mit-mit]

@kevmoo maybe would be good to update this bug now that Dart 2 is close to done?

[kevmoo]

--enable-asserts has been turned on everywhere.

@sigmundch should comment on where we ended up with dart2js – the big diff is the --omit-implicit-checksinstead of --trust-type-annotations, I think

[sigmundch]

As far as dart2js goes, we discussed about combining a few flags together and use a nomenclature that highlights more easily whether a flag is completely safe or is unsafe and requires careful testing. For example, something like --unsafe-optimizations=foo that gives the option of selecting different set of unsafe optimizations. You can select optimizations such as omit-implicit-downcasts, omit-covariant-parameter-checks, lax-runtime-type-to-string, and trust-primitives.

[sigmundch]

forgot to mention that we also agreed on adding a single flag that enables what we call the production mode that enables all the flags that are commonly used in production (and that may be adjusted with time in the future) for example, it would include --minify, all safe optimizations, and possibly some unsafe optimizations.

[kevmoo]

forgot to mention that we also agreed on adding a single flag that enables what we call the production mode

We have ~0 time to do this work though, right? CC @dgrove

[kevmoo]

Chatted w/ @sigmundch – we can clearly do better here. And clearly not needed for 2.0 stable.

[lrhn]

From the language perspective, there is only one flag that matters, and that's --enable-asserts. Strong mode in DDC had asserts enabled by default, which makes sense for a development compiler, but our deployment compilers will not want that. So, there will be a flag which enables asserts, likely --enable-asserts. The language specification currently says "In production mode an assertion has no effect and its execution immediately completes normally". We'll change that to "If assertions are not enabled ...", but that's all.

All other "modes" are not Dart language specification related. They are precisely compilers allowing themselves to go outside the language semantics, typically by not performing language required type checks. This is not specified anywhere, and it allows programs to exhibit non-spec compliant behavior.

(The --minify flag is not language relevant since the language specification never says anything about the actual string representation of the name of source entities at run-time, so it's not wrong, it just breaks some user expectations).

[mit-mit]

Re-surrecting this for Dart 2.1.

@mraleph what are the expected modes in 2.1 for the VM? Just 'regular Dart 2 mode' and a single option to --enable-asserts? It looks like the VM still accept the --checked flag, but not sure if that still does anything?

@sigmundch where did we end up wrt. the web tools?

[sigmundch]

For dart2js, we ended up deciding to put this in a notion of optimization levels. This is documented in detail here:
https://github.com/dart-lang/sdk/blob/34425a870e3cd5936079a81f17297b048c049077/pkg/compiler/lib/src/dart2js.dart#L650

[mraleph]

@mit-mit for VM right now we should only have asserts enabled / disabled distinction (I think --checked should just be a synonym of --enable-asserts).

[mit-mit]

OK, I suggest we entirely remove --checked as an accepted flag from the VM in that case.

[natebosch]

I suggest we entirely remove --checked as an accepted flag from the VM in that case.

That would be a breaking change. dart --help already doesn't mention it. dart --help --verbose mentions both checked and enable_checked_mode.

[Stargator]

@natebosch If dart --help doesn't mention it , then should it be removed? Or if not, then added to dart --help?

[natebosch]

If dart --help doesn't mention it , then should it be removed? Or if not, then added to dart --help?

There are lots of "hidden" options that most users don't need to worry about and aren't worth mentioning in the default help. Removing the option altogether is still breaking because someone could be relying on it in some script somewhere (maybe CI?) and when they upgrade their SDK that script would suddenly stop working.

[mit-mit]

If someone relies on getting 'checked mode' when they pass --checked to a Dart 2.x SDK, are they not already broken as no such mode exists?

And we did already state in Dart 2.0 that this was no longer supported:

https://www.dartlang.org/dart-2#migration

Dart no longer has checked mode.
Assert statements are still supported, but you enable them differently.

[mit-mit]

OK, per discussion we can wait with removing the --checked flag until 2.2; tracking in https://github.com/dart-lang/sdk/issues/34660.

Is there anything else to close out on, or can we mark the present issue as closed?

[dgrove]

We will close this on Tuesday unless there are objections.

[dgrove]

Closing.