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>
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>
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>
This CL implements the core flow analysis infrastructure for tracking
reasons why an expression was not promoted. It supports the following
reasons:
- Expression was a property access
- Expression has been written to since it was promoted
I expect to add support for other non-promotion reasons in the future,
for example:
- `this` cannot be promoted
- Expression has been write captured
- Expression was a reference to a static field or top level variable
These non-promotion reasons are plumbed through to the CFE and
analyzer for the purpose of making errors easier for the user to
understand. For example, given the following code:
class C {
int? i;
f() {
if (i == null) return;
print(i.isEven);
}
}
The front end now prints:
../../tmp/test.dart:5:13: Error: Property 'isEven' cannot be accessed on 'int?' because it is potentially null.
Try accessing using ?. instead.
print(i.isEven);
^^^^^^
Context: 'i' refers to a property so it could not be promoted.
Much work still needs to be done to round out this feature, for example:
- Currently the analyzer only shows the new "why not promoted"
messages when the "--verbose" flag is specified; this means the
feature is unlikely to be noticed by users.
- Currently the analyzer doesn't show a "why not promoted" message
when the non-promotion reason is that the expression is a property
access.
- We need one or more web pages explaining non-promotion reasons in
more detail so that the error messages can contain pointers to them.
- The analyzer and front end currently only show non-promotion reasons
for expressions of the form `x.y` where `x` fails to be promoted to
non-nullable. There are many other scenarios that should be
handled.
Change-Id: I0a12df74d0fc6274dfb3cb555abea81a75884231
Bug: https://github.com/dart-lang/sdk/issues/38773
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/181741
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
We're going to move this file into _fe_analyzer_shared, so we can't
have it importing CompilerContext. It turns out that we were only
using it to cache the decision of whether to display colors, and to
decide whether to verbosely explain how we made that decision. Those
can be accomplished in other ways.
Change-Id: If1e3a9fee7c0ca919444d8429936045b8408c246
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123840
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Add an incremental serializer that can be used to avoid re-serializing
the same thing again and again.
It does this by grouping libraries into Components / bundles,
serializing them individually and using the concatenated dill feature to
output the wanted data --- just potentially faster if we had the data
in cache.
Note that the serialized output might contain *more* than the input given
if we cached the wanted data into a bigger bundle.
The output will always be "closed" though, i.e. if the stuff that is
included that is too much added a new dependency, that dependency will be
included as well.
This should generally make it safe, although one can imagine situations
where it could pull in lots of dependencies that it wouldn't otherwise
have.
It is being driven by the incremental compiler which makes sure to
invalidate the cache when the data changes.
Except for situations where the libraries are changed externally after
being serialized, but before being serialized again, where one then wants
the updated library serialized, the feature should be safe.
Change-Id: I2a504abe6dbb68434c3b04abff13480ef72a6a6e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/120786
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
In preparation for creating a clean implementable interface for various
builder classes. This is in turn a precursor for deprecating
Builder.target
Change-Id: I83910e84da149775f46c0be4b10f7694fadd0a7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119843
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Add a lint to discourage importing the same file more than once.
The idea being that it was probably done by mistake (e.g. automatically
by an editor).
This is done in a number of places and they are currently added to the
status file.
Change-Id: I16bc9c04c5a607f87ead1fb34922a7edb408c3da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/113985
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL adds a test (lint_test.dart) that gives errors if using e.g.
"var foo = 42;".
We opted to not use the lint "always_specify_types" as that does
more than what the team voted for.
Change-Id: Ia37066ee04ff676d15f41222751557a9245f953f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/113032
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Sam Rawlins