Change --hide-package-warnings to --show-package-warnings and add hint on suppress warnings.

Change --hide-package-warnings to --show-package-warnings and add hint on suppress warnings.

BUG=
R=floitsch@google.com, rnystrom@google.com

Committed: https://code.google.com/p/dart/source/detail?r=33259

[floitsch, 2014-03-03 13:30:22]

LGTM.

https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
File sdk/lib/_internal/compiler/implementation/dart2js.dart (right):

https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
sdk/lib/_internal/compiler/implementation/dart2js.dart:562: Show warnings and
hints generated from packages that are not directly
What does "directly analyzed" mean?

I would keep the old text (unless you come up with something good).

[Johnni Winther, 2014-03-03 13:40:26]

https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
File sdk/lib/_internal/compiler/implementation/dart2js.dart (right):

https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
sdk/lib/_internal/compiler/implementation/dart2js.dart:562: Show warnings and
hints generated from packages that are not directly
On 2014/03/03 13:30:23, floitsch wrote:
> What does "directly analyzed" mean?
> 
> I would keep the old text (unless you come up with something good).

"directly analyzed" means given as entry point. If you run

dart2js package:foo/bar.dart

then warnings from 'package:foo' will always be shown.

[kevmoo, 2014-03-03 14:22:13]

On 2014/03/03 13:40:26, Johnni Winther wrote:
>
https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
> File sdk/lib/_internal/compiler/implementation/dart2js.dart (right):
> 
>
https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
> sdk/lib/_internal/compiler/implementation/dart2js.dart:562: Show warnings and
> hints generated from packages that are not directly
> On 2014/03/03 13:30:23, floitsch wrote:
> > What does "directly analyzed" mean?
> > 
> > I would keep the old text (unless you come up with something good).
> 
> "directly analyzed" means given as entry point. If you run
> 
> dart2js package:foo/bar.dart
> 
> then warnings from 'package:foo' will always be shown.


This changes the behavior we shipped in 1.2, right?

It's good to avoid this type of churn to shipping functionality unless there is
huge upside.

Please post a breaking change announcement to the announce alias so folks know
what to expect.

Also: will using the old flag now cause a crash? It might be worth a test. We
don't want folks who have scripted the old behavior to suddenly have no-ops and
not know that the feature changed.

[Bob Nystrom, 2014-03-03 21:29:34]

Pub change LGTM.

[Johnni Winther, 2014-03-04 07:16:15]

Committed patchset #2 manually as r33259 (presubmit successful).

[ahe, 2014-06-19 14:23:03]

https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
File sdk/lib/_internal/compiler/implementation/source_file.dart (right):

https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
sdk/lib/_internal/compiler/implementation/source_file.dart:126:
buf.write('\n$message\n');
Why did you add a newline before the message?

It ruins error parsing in Emacs as you cannot tell errors from info and
warnings.

[Johnni Winther, 2014-06-19 18:45:11]

https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
File sdk/lib/_internal/compiler/implementation/source_file.dart (right):

https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
sdk/lib/_internal/compiler/implementation/source_file.dart:126:
buf.write('\n$message\n');
On 2014/06/19 14:23:03, ahe wrote:
> Why did you add a newline before the message?
> 
> It ruins error parsing in Emacs as you cannot tell errors from info and
> warnings.

Because on the command line the hint (at the beginning of the line) was easier
to find than the error message (after the file and position typically 60+
characters to the right) which was very confusing.

[ahe, 2014-06-19 18:58:04]

https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
File sdk/lib/_internal/compiler/implementation/source_file.dart (right):

https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
sdk/lib/_internal/compiler/implementation/source_file.dart:126:
buf.write('\n$message\n');
On 2014/06/19 18:45:10, Johnni Winther wrote:
> On 2014/06/19 14:23:03, ahe wrote:
> > Why did you add a newline before the message?
> > 
> > It ruins error parsing in Emacs as you cannot tell errors from info and
> > warnings.
> 
> Because on the command line the hint (at the beginning of the line) was easier
> to find than the error message (after the file and position typically 60+
> characters to the right) which was very confusing.

Makes sense. I'll add a comment.

How would feel about having an optional "kind" parameter which is added before
the first newline?

[Johnni Winther, 2014-06-19 20:08:49]

https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
File sdk/lib/_internal/compiler/implementation/source_file.dart (right):

https://codereview.chromium.org/183833010/diff/20001/sdk/lib/_internal/compil...
sdk/lib/_internal/compiler/implementation/source_file.dart:126:
buf.write('\n$message\n');
On 2014/06/19 18:58:03, ahe wrote:
> On 2014/06/19 18:45:10, Johnni Winther wrote:
> > On 2014/06/19 14:23:03, ahe wrote:
> > > Why did you add a newline before the message?
> > > 
> > > It ruins error parsing in Emacs as you cannot tell errors from info and
> > > warnings.
> > 
> > Because on the command line the hint (at the beginning of the line) was
easier
> > to find than the error message (after the file and position typically 60+
> > characters to the right) which was very confusing.
> 
> Makes sense. I'll add a comment.
> 
> How would feel about having an optional "kind" parameter which is added before
> the first newline?

Sounds good.