Commit Graph

10 Commits

Author SHA1 Message Date
Jens Johansen 93f4ac0a83 [cfe] Actually have both ansi and plain text formatted messages (2nd try)
The CFEs FormattedMessage always had two getters to get the text inside
one that would supposedly give an ansi formated version of the message
and one that would supposedly give a plaintext formated version of the
message. They both returned the same string, though, which would either
be with ansi escape codes or plain text depending on the environment at
compile time.

This CL fixes that by having both messages, and letting the reporting
(i.e. whenever the message is read) decide which to use. That way we
can - for instance - report errors with color if the terminal supports
it correctly when reusing a dill (and reissuing problems, but where the
terminal support changes) and if printing the problem to an html <pre>
field (like observatory does).

It also cleans up two different implementations of whether we think
the terminal supports colors or not, by deleting one of them.

This is the second try. Patchset #1 is the original.
Patchset #2(and possibly beyond) is the changes.

TEST=Existing test suites.

Change-Id: I8e483049ce81ce1bd8e5396b588a31e0ad3a8630
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/187402
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
2021-02-26 13:06:17 +00:00
Jens Johansen 3a4a4f53d0 Revert "[cfe] Actually have both ansi and plain text formatted messages"
This reverts commit f63f7736c5.

Reason for revert: This somehow breaks the Windows bots. `python tools/test.py -n dartk-win-release-x64 standalone_2/io/process_shell_test`.

Original change's description:
> [cfe] Actually have both ansi and plain text formatted messages
>
> The CFEs FormattedMessage always had two getters to get the text inside
> one that would supposedly give an ansi formated version of the message
> and one that would supposedly give a plaintext formated version of the
> message. They both returned the same string, though, which would either
> be with ansi escape codes or plain text depending on the environment at
> compile time.
>
> This CL fixes that by having both messages, and letting the reporting
> (i.e. whenever the message is read) decide which to use. That way we
> can - for instance - report errors with color if the terminal supports
> it correctly when reusing a dill (and reissuing problems, but where the
> terminal support changes) and if printing the problem to an html <pre>
> field (like observatory does (1)).
>
> It also cleans up two different implementations of whether we think
> the terminal supports colors or not, by deleting one of them.
>
> (1) At least sometimes. It works - I think - only for 'evaluateInFrame',
>     but that's another story (and will be fixed in a follow-up CL).
>
> TEST=Existing test suites.
>
> Change-Id: Iedaedd9a5c41458d40c23ed4b706324c004ae943
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/186291
> Commit-Queue: Jens Johansen <jensj@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>

Change-Id: I0b53f943a61f76705badfead30d9e1ee35baff57
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/186941
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
2021-02-24 12:30:18 +00:00
Jens Johansen f63f7736c5 [cfe] Actually have both ansi and plain text formatted messages
The CFEs FormattedMessage always had two getters to get the text inside
one that would supposedly give an ansi formated version of the message
and one that would supposedly give a plaintext formated version of the
message. They both returned the same string, though, which would either
be with ansi escape codes or plain text depending on the environment at
compile time.

This CL fixes that by having both messages, and letting the reporting
(i.e. whenever the message is read) decide which to use. That way we
can - for instance - report errors with color if the terminal supports
it correctly when reusing a dill (and reissuing problems, but where the
terminal support changes) and if printing the problem to an html <pre>
field (like observatory does (1)).

It also cleans up two different implementations of whether we think
the terminal supports colors or not, by deleting one of them.

(1) At least sometimes. It works - I think - only for 'evaluateInFrame',
    but that's another story (and will be fixed in a follow-up CL).

TEST=Existing test suites.

Change-Id: Iedaedd9a5c41458d40c23ed4b706324c004ae943
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/186291
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
2021-02-24 10:33:45 +00:00
Johnni Winther 34fb48bb8a [kernel,front_end] Migrate first wave of pkg/kernel and pkg/front_end
Migrates libraries dependent only on already migrated libraries.

Change-Id: I0e85ee8dbc2afce031b92e0009e71c206a55af28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179502
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
2021-01-18 15:40:21 +00:00
Konstantin Shcheglov 44b8d530a2 Remove 'template' from Code.
Change-Id: I1937e22ba22ba7a0ae809d777f2e61b046519fd6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/176021
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
2020-12-14 16:57:18 +00:00
Konstantin Shcheglov 3d67e6f998 Migrate _fe_analyzer_shared to null safety.
Some notes.

1. `Token.next` is `Token?` because there are null(s) for comment tokens.
  But I think that it is never `null` in code, because there is at
  least EOF token. So, lots of `!` null checks.

2. `Link.tail` is never null when `isNotEmpty`, but the type system
  cannot express it. So, some number of `!` null checks.

3. I keep assert(s) for now, and use comment
  `// ignore: unnecessary_null_comparison`.

4. I disabled `can_get_rid_of_nnbd_issue_error`, I think it fails
  because of changes in `_fe_analyzer_shared` language version.

Smoke test in google3 looks green.
https://test.corp.google.com/ui#id=OCL:346825148:BASE:346841611:1607632317129:6e87bf7

I have not tried yet full TAP, will do in the evening.

I have not tried yet Golem, or looked at benchmarks.

Change-Id: I651301e5d3a851dd77d73af960dac779cb0fc991
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175620
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
2020-12-12 03:22:29 +00:00
Jens Johansen 7b75bd8ece [CFE] Special case StrongModeNNBDPackageOptOut message in IncrementalCompiler
This CL fixes the wrong message, so - when in the process of fixing
the package nnbd settings - one gets the correct message, mentioning the
right packages and no longer mentioning the fixed ones.

Change-Id: Ied26094055e56b44dfdd2e942b98eb9e1e7968fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170423
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
2020-11-05 09:43:23 +00:00
Jens Johansen 60a5c58196 [CFE] Fix not getting rid of NNBD error in package in incremental compiler
This fixes the issue of the error not going away, but can (see added
test) give a wrong error message when in the process of fixing the issues.

A follow-up CL will (try to) correct the wrong error message.

Change-Id: I3547fe5fb5cfd179897996029a00a4995a967e54
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170422
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
2020-11-05 08:47:42 +00:00
Johnni Winther 00c2962db8 [cfe+analyzer] Move messages, scanner and parser to package:_fe_analyzer_shared
Change-Id: I4fa87aee65f30a9868a6cf8f0342591869ece7ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123663
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
2019-11-01 09:37:57 +00:00
Jens Johansen 014124e763 (Some) DiagnosticMessages can be serialized to/from json.
This is needed to serialize and deserialize problems to dill and
re-issuing problems as needed.

Change-Id: Id22d1c86f43b1b08c5e5a4d133869075e9b0c100
Reviewed-on: https://dart-review.googlesource.com/c/91743
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
2019-02-01 11:07:27 +00:00