First step in implementing non-function type aliases in the analyzer:
Just add the new back-references in types, such that they can refer to
a type alias which was used to obtain the type, if any.
Next step: Preserve the aliasElement and aliasArguments in summaries,
next again: Create `TypeAliasElementImpl` and ensure that the parser
can create them.
Change-Id: I1bfbc2c3893e32c5b1826552361a0238aa2b4058
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169380
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Reason: causes Flutter analysis performance regression.
https://github.com/flutter/flutter/issues/68716
We will get back to applying resolution after loading AST when
we switch to the binary format, and so recover enough performance.
WIP for it: https://dart-review.googlesource.com/c/sdk/+/168260
Unfortunately this means that it will get even bigger.
Revert "Separate AST from resolution (per declaration)."
This reverts commit 4d6fba37de.
Revert "Remove commented out code from LinkedUnitContext."
This reverts commit c4f2c8ec3e.
Revert "Issue 43890. Implement applying resolution to IndexExpression."
This reverts commit 088524efa6.
Revert "Issue 43888. Fix for applying resolution to PropertyAccess in cascade."
This reverts commit 1f660a7acf.
Change-Id: I808c1fc62161458d7544d7741e4b358c99b0b55f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168881
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This logic allows us to migrate code like this:
int firstEven(Iterable<int> values)
=> values.firstWhere((i) => i.isEven, orElse: () => null);
Into:
import 'package:collection/collection.dart' show IterableExtension;
int? firstEven(Iterable<int> values)
=> values.firstWhereOrNull((i) => i.isEven);
Rather than the default behavior, which would migrate it to:
int? firsteven(Iterable<int?> values)
=> values.firstWhere((i) => i!.isEven, orElse: () => null);
(The new migration is far superior because it doesn't require the
input iterable to accept null).
This functionality is disabled at the moment, because:
- The changes it makes don't show up properly in the web preview.
- The pubspec is not yet properly updated.
I will address these issues in follow-up CLs and then enable the
feature.
Change-Id: I96f3b12d682c586631920b38406bad6aa3f4789e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168500
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
They are not expressions, and so don't have types.
Actually setting a type for a constructor of a generic class breaks
summary serialization because `T Function()` type of the constructor
`class A<T> { const A.named()l }` is not valid - `T` is not in scope.
So, this crashed the linker.
Change-Id: I25a6e5eb6902faa479e4dcb683ef3936af07b5b9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168420
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Previously, we were assuming that each path in `binPaths` was just one
level deeper than the corresponding source code path, and therefore we
could map a path in `binPaths` to the corresponding source code path
by just removing the first directory (e.g. map `bazel-out/foo/bar` to
`foo/bar`). But this isn't correct: the paths in `binPaths` are more
deeply nested, e.g. `bazel-out/k8-fastbuild/bin`. This CL changes the
algorithm to use `context.relative`, so that we get the correct path
mapping regardless of the nesting depth.
Change-Id: I870a7fca18e689691efcc32da527135643255eca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168127
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This adds checks for three cases:
- error codes for diagnostics that are not being produced,
- error codes that can't be ignored (with a severity of error), and
- error codes that are already being ignored.
I originally also checked for names that are not defined as error codes
(which turned up at least one valid issue in the Flutter repo), but we
don't have a list of all valid names against which to compare because
plugins can add new diagnostics.
It should be noted that, as written, these diagnostics can't be ignored,
despite being hints. The reason is as follows: in order to detect
diagnostics that are not being produced, these checks need to have a
list of the diagnostics that _are_ produced. If an ignore comment
attempted to ignore one of these hints, this validation would occur
before the hint had been generated, so that comment would in turn appear
to be unnecessary.
If we need them to be ignorable, then we can special case them so that
they are never reported as being unnecessary.
And after running this over the Flutter repo I commented out two of the
three codes because there are violations. Many of the violations are
valid and need to be cleaned up. Some are the result of "ignore" being
used for other purposes. The Flutter team has said that we can replace
their use of "ignore" in order to enable these hints, but I don't have
time to do that right now and I'd like to get this landed before it bit
rots again.
Change-Id: I1704105621bef5a5c49202267c99aa1d950a26a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156402
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
If this diagnostic needs to be generated, then I can create an issue to
track that work, but I think we handle it by not defining the private
fields in our models, which means the issue is reported as an undefined
getter.
Change-Id: I8d220adf0d11b2c65f8953eec57a87f86f520d74
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167100
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This adds some technical debt in form of using writeOrReadElement in
clients, which can be paid incrementally by migrating these places to
handling assignment like expressions one by one. Doing it all in one
CL was too much. But now the underlaying AST resolution will be
sound.
In the next breaking change we will remove
setAssignmentBackwardCompatibility(), so stop setting elements/types
for assignment targets.
Change-Id: I11626876cfed25653edb0cc18544aba51cef5965
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/165622
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Konstantin Shcheglov