The parser now generates a ConstructorWithTypeArguments error and a new
handleInvalidTypeArguments event after a begin/endTypeArguments event pair
when those type arguments are in a syntatically invalid location.
For example: `new C.n<int>();` in
```
class C<T> { T f; C.n() {} }
main() { var x = new C.n<int>(); }
Most listeners handle this event by dropping the invalid type arguments,
but AstBuilder now preserves those invalid type arguments in the AST
to support better code quick-fixes/quick-assists/refactoring.
Change-Id: I5b22bd4903cd9ee3645936b9a108598b603cf9ca
Reviewed-on: https://dart-review.googlesource.com/c/79300
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
Also, remove it from ErrorVerifier.
R=brianwilkerson@google.com
Change-Id: I35f6f7fd2f8c6680ec470e7bf7da4780a3c69df3
Reviewed-on: https://dart-review.googlesource.com/c/79360
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Includes a fabricated base type for file operations to avoid a List of a Union.
Change-Id: I0ddc7c6428cc8f1535c3a8d7d0b042b1725969f3
Reviewed-on: https://dart-review.googlesource.com/c/79323
Commit-Queue: Danny Tuppeny <dantup@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Its only use was in formatting an internal error message that
generally only fires in unit tests if we have significant bugs in
summary logic. Eliminating it doesn't really make the error any more
difficult to debug, since it is easy enough to stop the unit test in
the debugger and examine the data structures manually.
Addresses code review comment
https://dart-review.googlesource.com/c/sdk/+/79145/1/pkg/analyzer/lib/src/dart/element/element.dart#7737
Change-Id: I17f18e1e4abfac4c5dd9067706fabc9bc4de7cff
Reviewed-on: https://dart-review.googlesource.com/c/79282
Commit-Queue: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
It didn't work properly anyhow (see issue #34657). Changed the call
sites to use GenericTypeAliasElementImpl.instantiate, which does have
the correct behavior.
Change-Id: I4b9c6cc8ddfcf3b0bebe40b7d874c4630c4b5ae4
Reviewed-on: https://dart-review.googlesource.com/c/79283
Commit-Queue: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Dart for-in loops allow `var x = [1]; for (var x in x) {}`, which is not
allowed in JS. If this pattern is detected, a temporary variable is
introduced so the for-in initializer expression is evaluated outside of
the JS for-of loop.
(This issue seems to be unique to for-in loops. For loops and other
kinds of variable declarations of the form `var x = ...` are not
allowed to use `x` in the initializer, even if `x` is declared in an
outer scope.)
Also fixes an out-of-date comment in the DDC+Analyzer backend.
Change-Id: I35b272a5a311f7b6f104cc82a99cc83a6ed5c247
Reviewed-on: https://dart-review.googlesource.com/c/79142
Commit-Queue: Alan Knight <alanknight@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Alan Knight <alanknight@google.com>
The methods addBundle and createPackageBundle were previously in the
derived class SummaryLinkerTestStrategy, but there's no reason they
have to be there; they don't rely on any functionality that's specific
to linker tests. Moving them will allow additional summary tests to
make use of package bundles.
Change-Id: I988147c76e6dcfef5ef0f000d66b1639b4b3ecf7
Reviewed-on: https://dart-review.googlesource.com/c/79280
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Working towards making it compile, free of lint errors, formatting correctly.
Change-Id: I61d5ed6e89fdf24c97079745a3816b1b303e2820
Reviewed-on: https://dart-review.googlesource.com/c/79201
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
Change-Id: Ib9f80ef29cc301b0a8354bcaeddaf47177784d9c
Reviewed-on: https://dart-review.googlesource.com/c/79203
Auto-Submit: Peter von der Ahé <ahe@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Peter von der Ahé <ahe@google.com>
Temporarily using "legacyMode" instead, but I plan to rid these soon.
Change-Id: Iff8bcde03b6ebe4ad95f963f456c855e73e58926
Reviewed-on: https://dart-review.googlesource.com/c/79042
Auto-Submit: Peter von der Ahé <ahe@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This is necessary to ensure that type parameters that refer to the
enclosing context get serialized correctly.
Change-Id: I1e95cc4e83be76bf003faa037eff80728c1fb748
Reviewed-on: https://dart-review.googlesource.com/c/79145
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This experiment didn't work out--it turns out that too many clients
were relying on the performance characteristics of unlinked summaries.
Change-Id: I3e7c54c18b5b02ee0df17ef5d62e1f6a7e35da68
Reviewed-on: https://dart-review.googlesource.com/c/79144
Commit-Queue: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Change-Id: I9fd0b2031ceb7c7831a7131c11c3848dbf3f336e
Reviewed-on: https://dart-review.googlesource.com/c/79143
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This name is not used by most module formats, but we do use it with the
legacy format.
Change-Id: I8d2f36b12a60b37d0460b57d5a360ba21b4e0476
Reviewed-on: https://dart-review.googlesource.com/c/78923
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
But still keep it using the old InheritanceManager.
R=brianwilkerson@google.com
Change-Id: I58f9187a97fc161215614ed55d6e08007f31595c
Reviewed-on: https://dart-review.googlesource.com/c/79080
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
- Fixes to generation from spec
- Add basic code-gen with (very incomplete) tests
- Add some basic parsing of TypeScript interfaces in the LSP spec
- Add a group to the test
- Add code for extracting TypeScript codeblocks from Markdown
Change-Id: I733756d43744d89307b77527bd083cfacf670f56
Reviewed-on: https://dart-review.googlesource.com/c/79046
Commit-Queue: Danny Tuppeny <dantup@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Also remove any calls that aren't required. The function still works if you pass it a relative path (for convenience, if you have a variable) but it's not required for relative paths.
Change-Id: I567e098f5956a7c2b5fe2d6d7d7fb16a263a72cc
Reviewed-on: https://dart-review.googlesource.com/c/79025
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
The CL is reverted because it didn't account for the case when a check
of a user-specified type argument against the bound depends on another
type that is only known after type inference is done.
Change-Id: I1fd140af95ed37b9191a5b161a281d4639e3453f
Reviewed-on: https://dart-review.googlesource.com/c/79048
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Change-Id: I60f72904f4a9ae3427b2a2633a22f70a6b6f8ea9
Reviewed-on: https://dart-review.googlesource.com/c/79020
Commit-Queue: Peter von der Ahé <ahe@google.com>
Auto-Submit: Peter von der Ahé <ahe@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This makes explicit downcasts more efficient by re-using the
optimizations we already have for implicit downcasts.
For implicit/explicit as checks we use the symbol to distinguish which
exception to throw if the check fails. So this does not actually
require unification of _CastError and _TypeError.
Issue https://github.com/dart-lang/sdk/issues/34582
Issue https://github.com/dart-lang/sdk/issues/30632
Issue https://github.com/dart-lang/sdk/issues/30571
Change-Id: I7b8818d2698e249c90a3e1b8790bad69ada649a9
Reviewed-on: https://dart-review.googlesource.com/c/78748
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The test isn't normally run, and all 12 testcases caused a crash.
Change-Id: Ie1576e32b70f01aa775c3305bff2bc992eebf86f
Reviewed-on: https://dart-review.googlesource.com/c/78940
Auto-Submit: Peter von der Ahé <ahe@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
--unsafe-package-serialization saves the frontend_server from having to
re-serialize everything all the time.
Before this CL, though, things could go wrong:
If you had a situation where you had previously compiled a file that
depend on a package A, and where (some of) package A depends on
package B this would happen:
- All of package A was serialized together.
- All of package B was serialized together.
When later, you compile something that depend less on package A - namely
on only on parts that does not depend on package B, but is included in
the previously serialized package A, the following would happen:
- The new (non-package) libraries would be serialized.
- Package A serialization would be reused.
This is basically fine: Running the app would be fine, everything it
actually depend on is there.
However, if the VM is forced to compile everything it now also compiles
stuff that was included - but really unused - from package A - namely
also the libraries that depend on package B --- which is not included.
This CL changes the last part by also including package B.
The result is that even more unused libraries are included, but that
the VM can survive a forceful compile.
Note that the --unsafe-package-serialization is only used for tests,
so the "including even more unused" part is probably not a big deal,
and all in all there's still a big speed advantage to doing this.
Change-Id: Iac06ba6f40c2caaacce641c5853e9491496dce53
Reviewed-on: https://dart-review.googlesource.com/c/78541
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This will allow us to create a synthetic
GenericFunctionTypeElementForLink representing the function type
defined by an old-style typedef. That in turn will be necessary to
fix some incompatibilities between the summary linker and element
model representations of typedefs.
Change-Id: Ia3622d58cac25976022bf79a0ac47b190f1f411c
Reviewed-on: https://dart-review.googlesource.com/c/78920
Commit-Queue: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
To allow ddc sdk kernel generation internally, add a way to provide
paths to dependent files explicitly, instead of assuming relative from
Platform.script.
Also remove .packages file parameter. We don't have this file internally
and sdk shouldn't depend on any of packages anyway, so it just work
without this option.
Change-Id: Iec892cbb640d35e64d107c6af36d214632815bae
Reviewed-on: https://dart-review.googlesource.com/c/77485
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Auto-Submit: Ivan Naydonov <inayd@google.com>
We now determine whether a type is simply bounded in the summary
linker, so that we can take advantage of the linker's circularity
detection logic.
Fixes#34635.
Fixes#34636.
Change-Id: I6c5040dbaeb79957d8a84e3f76e6a51834b57f05
Reviewed-on: https://dart-review.googlesource.com/c/78867
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
