Reverse accidental enabling of 'use strict' in closure compiler

third_party/closure_compiler/closure_args.gni

 # Copyright 2015 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 # Args for all uses of the closure compiler
 common_closure_args = [
   "extra_annotation_name=attribute",
   "extra_annotation_name=demo",
   "extra_annotation_name=element",
   "extra_annotation_name=group",
@@ skipping 35 matching lines @@
   "chrome_pass",
   "polymer_pass",
 ]
 
 # Additional closure arguments for minifying
 minifying_closure_args = [
   "compilation_level=WHITESPACE_ONLY",
 
   "language_in=ECMASCRIPT_NEXT",
   "language_out=ECMASCRIPT6",
+  "emit_use_strict=false",

[dpapad, 2017/06/05 17:31:31]

Can you elaborate a bit on what is the exact problem caused by "use strict"? In
general "use strict" makes JS usage more sane, so I would prefer
 - keeping it
 - If we can't keep it, figure out exactly why.

 If some code fails in strict mode, this usually indicaten some other problems
that can be fixed alternatively.

Specifically see
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode,
section "Converting mistakes into errors"

[wychen, 2017/06/05 17:35:08]

I agree enabling "use strict" is the right direction for us. However, I believe
we've turned this on by accident and caused regressions. See crbug.com/728655.

We can turn it on after fixing the known issues.

[dpapad, 2017/06/05 17:51:23]

I see.  Can you file a bug listing the known issues and add a TODO pointing to
this bug here? I am hoping that this would increase the possibility of this
issue being addressed in the future (FWIW the phrasing in the bug makes it sound
that it  won't be fixed anytime soon).

Also, what is the difference between "emit_use_strict" and "strict_mode_input"?
The commit at
https://github.com/google/closure-compiler/commit/5279eb46b805f4a8c8d066a0b6d...
suggests that strict_mode_input should be used to opt out of the new default
behavior.

[wychen, 2017/06/05 18:25:56]

I'll add a TODO.

The thing I worry the most is the testing coverage. "use strict" only changes
the runtime behavior, and we might not have exercised them enough in our
automated tests.  Many of the JS is used in the web UI, and that's not where our
coverage is best.

The only known issue is documented in that bug (dom distiller). This might be a
bit ironic since some of the "use strict" violations come from code generated by
(older version of) closure_compiler.
I tried strict_mode_input=false but somehow it didn't remove the "use strict"
output.

[wychen, 2017/06/05 20:21:54]

Done.

 ]
 
 # For compatibility with old uses.
 default_closure_args = common_closure_args + checking_closure_args
 
 default_disabled_closure_args = [
   "jscomp_off=duplicate",
   "jscomp_off=misplacedTypeAnnotation",
 ]