No more flag, always parse into the new AST, always visit new AST nodes,
always return them as child entities, parent-child structure reflects
the new AST.
So, use `namePart` and `body` where possible. Deprecate previous
properties.
This is still de jure a breaking change, because `parent` of deprecated
properties changes. De facto this required very few changes in google3.
Once this CL lands, I will publish `analyzer 10.0.0`, migrate everything
to new properties, delete deprecated properties, and publish `analyzer
11.0.0`.
Maybe deprecate `NamedCompilationUnitMember.name` and migrate to
subclass specific `name` or `namePart` properties before publishing
`analyzer 10.0.0`. This part is not breaking per se.
* Deprecations in `ClassDeclaration`:
* Properties `leftBracket`, `members`, `rightBracket` are deprecated, use `body` instead.
* Properties `name`, `typeParameters` are deprecated, use `namePart` instead.
* Deprecations in `EnumDeclaration`:
* Properties `leftBracket`, `constants`, `members`, `rightBracket` are deprecated, use `body` instead.
* Properties `name`, `typeParameters` are deprecated, use `namePart` instead.
* Deprecations in `ExtensionDeclaration`:
* Properties `leftBracket`, `members`, `rightBracket` are deprecated, use `body` instead.
* Deprecations in `ExtensionTypeDeclaration`:
* Properties `leftBracket`, `constants`, `members`, `rightBracket` are deprecated, use `body` instead.
* Properties `constKeyword`, `name`, `representation`, `typeParameters` are deprecated,
use `primaryConstructor` instead.
* **Breaking Change:** While the deprecated members mentioned above still exist in the AST,
their parent nodes have changed. This means that code relying on specific parent-child
relationships for these nodes might break.
Bug: https://github.com/dart-lang/sdk/issues/61701
Change-Id: Ic48104da8b029c9b454bbd2336574b7823025565
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461841
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
The null assert in `PropertyAccessorElementImpl.variable` is safe
because `ElementBuilder` always creates synthetic
`TopLevelVariableFragmentImpl` or `FieldElementImpl` for a getter or
setter. And the other way around, non-synthetic
`TopLevelVariableFragmentImpl` or `FieldElementImpl` when created
associate itself with synthetic getter / setter.
Change-Id: I40e4ce866edffab6c8bcdf6e408bd1bbfbba6581
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442246
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
As much as I don't like the scale of changes, there is no valid variable in these cases. So, we express this explicitly, without trying to pretend that there is on. Or crashing as we did without this CL.
Change-Id: I74cef1d3d9d3cba6985d83b98be361cca09170f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/355300
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Maybe? With an explicit type check we don't try to make an impression
that anything more happens here, e.g. for type parameters.
Similarly, for https://github.com/dart-lang/sdk/issues/36697 we would need to introduce `InvalidType`, which is not `DynamicType`. And so, `DartType.isDynamic` should not return `true` for `InvalidType`, it is not a property that various types may have, and should be replaced with explicit `is DynamicType`.
We also have `UnknownInferredType`, but it should never leak to clients.
Change-Id: I302b06355143d97bb52922c805dbad585a522e0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288340
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This is necessary to separate `ClassElement`, `EnumElement`, and `MixinElement`. And, in the future, augmentations like `ClassAugmentationElement`, etc.
Change-Id: Iecd2f8707212e53ef56f0e101880c7bab9e5d057
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254104
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
For `InterfaceType` keep `element2` deprecated and define
`InterfaceElement get element2` instead. Most changes are because
of this.
Change-Id: I13b888610fc707438c3c97b676f1460e7fc2b040
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253564
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
When we resolve a file partially, there is no fully resolved
CompilationUnit. So, anything we create for completion should be
based on element models and a resolved, or unresolved AstNode.
In a following CL I will make it possible to create instances of
DartCompletionRequest based on such element models and node.
Change-Id: Ief7e376588bb63f4d898e33299a9fd2014c88843
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219748
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I believe that this approach will make it much easier for us to make
changes to the ranking order for some suggestions without significantly
changing the ranking order of others. In particular, adding a negative
feature for a subset of suggestions (such as decreasing the rank of
methods named 'noSuchMethod') currently has the effect of decreasing the
rank of everything that isn't a method. This solved that problem by
giving all features a baseline of zero and allowing features to either
increment or decrement the rank from there.
This CL has minimal overall impact on ranking except in the following
areas (values are the inverse mrr):
- keyword void, which regresses from 150.766 to 237.838 (87.071 points)
- local function, which regresses from 24.941 to 173.016 (148.075 points)
- prefix, which improves from 386.455 to 361.611 (24.844 points)
- type parameter, which improves from 269.235 to 249.489 (19.746 points)
The change to 'keyword void' largely shows up in return types of function
declarations, but interestingly enough has little impact on the return
type of method declarations. We might be able to offset this by treating
`void` (and `dynamic`) as types rather than as keywords. I've added that
work item to the list.
The change to local functions doesn't appear to impact any individual
location significantly, and might not be significantly detrimental
because local functions are probably not all that common.
Change-Id: Ifc7002cd6a9d656792ad4ffd76d96df2ab50e4a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/181900
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This doesn't significantly improve the overall scores, but it does cause
the element kind to be used for available declarations, which means that
constructors are suggested before classes.
Change-Id: I75e7bb13bd867b9209a43c4d737c5079c42eb25a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154080
Reviewed-by: Jaime Wren <jwren@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
and the available declarations support.
The resulting metrics are lower than I'd like them to be, but I suspect
that this will be a reasonable first step toward the final solution.
Change-Id: Ib5d471a9d3c0dafcb2b3687e25b9af21da97854a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149860
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The code to check the element kind was not being used in a few places
because (a) the generator wasn't always generating a table when it
should and (b) the key for the table wasn't always being set when
creating the OpType. Both of these issues have been mostly addressed.
That required re-generating the element kind tables.
There were several places where context type information wasn't being
used when building suggestions. This has been fixed for all the places
I'm currently aware of.
There were a couple of places where the context type wasn't being
computed where it could have been. I have fixed the places I'm aware of.
Context types were not being computed anywhere because of a bug that
has now been fixed.
There is now one place that computes and caches the context type, which
should improve performance slightly.
I also removed some dead code that I discovered in the process of making
the other changes and cleaned up a couple of places in the code that
were suboptimal.
Change-Id: Ieae8dcc71b986841be3078d6e0b3a653c35384b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148237
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This should have tests, but I (or someone else) need to do some data
mining to figure out the correct relevance values and hence the correct
ordering to test for.
Change-Id: I7782d7b7e13ff38a785c445cd0d6fc82a388a6aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141000
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Konstantin Shcheglov