If an identifier starts with a non-ascii-character and has a comment
an assert was triggered about the comment not being attached to the
token. This CL attaches the comment to the token (which it should be)
and thus avoiding the assert trigger.
Change-Id: Id261970b88ca721d4b3a996abfb8ff43f0ec8341
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/161102
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
a) front_end is not published anyway so it shouldn't hurt.
b) Having some specific version is potentially (and likely) wrong as
it is only every compiled against the path version and thus likely
also only compatible with the path version.
c) If one were to make a project with it's own path-override to point
to front_end (and e.g. kernel) running pub get on that wouldn't work
because one would thus have two kernel versions (the wrong version
one in front_end/pubspec.yaml and the path one added in the other
project.
Change-Id: Ia37dec7db7ccee677a38dd771f938c5089bbc522
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/161103
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Rename test.options files and TestOptions to folder.options and FolderOptions,
respectively. Rename link.options files and LinkDependencyOptions to
test.options and TestOptions.
This is to better reflect the current usage of these options.
Change-Id: Ibd3c49fa5bd1c9ce8a9eb5910417c12cd45845d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160723
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
When a crash occurs in Uri it doesn't include the content of the failing
Uri, making it very hard to determine why the error situation occurred.
With the change the offending Uri will be printed as part of the message.
Change-Id: I41bb9762e5fc8deb97e051adaf336ecf3599a901
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160281
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds a mechanism similar to that used in async functions where
exceptions are caught in the synthetic code and passed into the
generated body to be rethrow'n.
This ensures the exception is throw'n from the same place as the
original yield*, as per the spec.
Bug: https://github.com/dart-lang/sdk/issues/42466
Change-Id: I553dd89141985f6f30751913a1c8a62b1229af04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158543
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This CL basically change two things about the sorting:
* Entities are not sorted according to metadata. Metadata just follows
along. Before "@a class B {}" would come before "class A {}" because
"@" comes before "c". Now "class A {}" comes first because "A" < "B".
* Sorting happens on a token level, i.e. "F<int>" will now come before
"F2<int>" because "F" < "F2" whereas before it was the other way
around because "F2" < "F<" (because "2" < "<").
None of it really matters as long as sorting is done the same way when
comparing the outlines.
Doing it this way makes it faster and actually brings the runtime
(in benchmarks) less than the old (now deleted) textual outline.
Change-Id: Ib1d887ab0c14519316c8e9a3da38f0dd49b4104f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/159041
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This version generally produce the same output (with slight variations
for spacing between some elements as well as for unassociated metadata)
but is slightly slower in modelled (i.e. sorting) mode.
The slow-down is remedied (so the whole thing actually becomes slighly
faster) if sorting slightly differently than the old version. That is
for another CL though.
Change-Id: Id19df710dff965250bfb7cf51d8756394cbe2067
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/159080
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Before this CL the textual outline didn't know about imports and exports
and thus couldn't sort them.
This CL makes it know about them and allows imports and exports to be
sorted internally, but not mix with other stuff (e.g. imports should be
placed after "foo() {}" just because "f" comes before "i", but putting
"import 'a.dart'" before "import 'b.dart'" is OK.
This CL does not sort the hide and show entries.
Change-Id: Ic640cdaa98ac3562f8b36b21180a26584cb6d205
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158551
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Before this CL the textual outline didn't know about named mixin
applications which caused it to insert "fences", i.e. splaces it
wouldn't sort across.
So for instance
class E {}
class D {}
class C<T> = Object with A<Function(T)>;
class B {}
class A {}
would not be sorted fully because class C is a named mixin application,
something it didn't know about, and it would only allow stuff on either
side to be sorted. So the sorted output would have been
class D {}
class E {}
class C<T> = Object with A<Function(T)>;
class A {}
class B {}
With this change it knows about it and the output would now thus be
class A {}
class B {}
class C<T> = Object with A<Function(T)>;
class D {}
class E {}
Change-Id: I97b28706732582d0c37f1b2c052b9f6eaf862a5a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158550
Reviewed-by: Johnni Winther <johnniwinther@google.com>
E.g. before this change an empty class output would have been
class Foo {
}
now instead it becomes
class Foo {}
this matches what the formatter does.
Change-Id: Id08edc5259bae00deff9a66b4ae745f21c192358
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158549
Reviewed-by: Johnni Winther <johnniwinther@google.com>
E.g. before this change a procedure output would have been
foo() { }
now instead it becomes
foo() {}
this matches what the formatter does.
Change-Id: Ieb538d61e527cbec26d1d65ed6de349311dd0163
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158548
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The new logic classifies the LHS and RHS of the equality check as
either null, non-nullable, or potentially nullable, and then either
promotes, treats the expression as equivalent to a boolean, or does
nothing, as appropriate.
This means, for example, that a comparison between a non-nullable
value and `null` is now known to evaluate to `true` for reachability
analysis.
Note: as part of this change, it was tempting to trigger promotion
whenever a varialbe is equality compared to an expression of type
`Null`, but this would be unsound (consider `(int? x) => x == (x =
null) ? true : x.isEven`). So we still only promote when the variable
is compared to a literal `null`.
Fixes#41985.
There's a corresponding spec change out for review:
https://github.com/dart-lang/language/pull/1134
Change-Id: Id7f1d4eaa3b0fa57124445bb8352eef32c304feb
Bug: https://github.com/dart-lang/sdk/issues/41985
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155926
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The widget transformer would try to pass on the location injected
parameter in the factory constructor when calling constructors of its
own kind in constructor body. For instance
class Foo extends Widget {
factory Foo() => new Foo.internal();
Foo.internal();
}
would be transformed into
class Foo extends Widget {
factory Foo({Location loc}) => new Foo.internal(loc: loc);
Foo.internal({Location loc}) : super(loc);
}
This doesn't work if the constructor invocation is constant. For
instance:
class Foo extends Widget {
factory Foo() => const Foo.internal();
const Foo.internal();
}
which would be transformed into
class Foo extends Widget {
factory Foo({Location loc}) => const Foo.internal(loc: loc);
const Foo.internal({Location loc}) : super(loc);
}
Here the reading of the injected factory parameter [loc] is not a
valid constant, leading to a compile-time error during constant
evaluation.
To handle this, const constructor invocations within factories do
not pass on the location from the surrounding constructor but
uses their own. For instance:
class Foo extends Widget {
factory Foo() => const Foo.internal();
Foo.internal();
}
will be transformed into
class Foo extends Widget {
factory Foo({Location loc})
=> const Foo.internal(loc: const Location());
Foo.internal({Location loc}) : super(loc);
}
This does mean that these constant widgets will all have a
location based on the factory constructor declaration and _not_
one per invocation of the factory constructor.
Related to https://github.com/flutter/flutter/issues/63335
Change-Id: Ie3300d3ba81324d5fbd7fb6ab72b9d83d7afcf22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158395
Reviewed-by: Jens Johansen <jensj@google.com>
This CL:
* Adds the textual outline suite to the suite runner run by the bots,
hopefully ensuring that we won't forget about them in the future;
* Adds the missing textual outlines and status entries to make the
textual_outline suite pass.
Change-Id: I0434b6a8e19019bbae7457ea738a13f2623f0c3c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158542
Reviewed-by: Johnni Winther <johnniwinther@google.com>
E.g. class Foo extends Bar, Baz {} would before have parsed weirdly,
but it will parse as you'd (probably) expect with an error saying
you cannot do that. For now at least both CFE and Analyzer will
pretend like you just specified the first one but I suppose Analyzer
could for instance use the extra information to propose converting
other ones to implements clauses or similar.
Fixes https://github.com/dart-lang/sdk/issues/22313
Change-Id: I180cdd8ab07143dd74fd21c9976ec2a46c428d8e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158261
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Although this error condition is not reported by the parser, the
language grammar does not it, so from a customer perspective it is a
parser error. Accordingly, it has been assigned a ParserErrorCode and
is reported by the AstBuilder, as we do for other similar errors.
Change-Id: I22aad9b0acd27bf6e60dfb393837d48a49fc336b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158365
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This avoids adding forwarding stubs on all subsequent subclasses by
using the result of the superclass member computation in subclass
member computation.
Change-Id: Id9ae4a8e7b0fbfe90c863580f056bf9d6266220f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157322
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Jens Johansen