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>
I couldn't think of any useful features to use when ranking overrides. I
briefly considered `deprecated`, but even deprecated members might need
to be overridden until all implementation of the member can be deleted.
Change-Id: I994d4177b1111ebdf44a223f975422779c5a8ae8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140005
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Sorry for the size of the change.
This started out looking like a fairly simple task of repeating the work
done for type mambers, but it was too similar so I ended up doing some
refactoring in order to share the code.
Along the way I realized that we didn't yet have a feature for demoting
deprecated members, so I added it.
Then I discovered some more places where the old and new logic were
getting intertwined, so I straightened that out as well.
Change-Id: Ic24babd30bbbeeae9709a8019642e497a2ebb65d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139949
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Other than
- the change to enable the lint (in analysis_options.yaml) and
- updates to the generator (in tool) to stop generating 'new',
all of the changes were generated by dartfix.
Change-Id: I9d14b99ab748ef5b80f8800a802e20100eee04a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128577
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This reverts commit fbfe5691cb.
Reason for revert: Subtle backwards incompatibility, with no obvious win-win fix.
Original change's description:
> Change completionTarget.forOffset to accept & wrap dangling AstNodes.
>
> Deprecate the entryPoint parameter, but still accept it in place of what
> used to be (positionally) compilationUnit.
>
> Detect if we have a compilation unit or not; and in the case we don't,
> add a new protection by asserting that it has no parent (its the root of
> the dangling tree).
>
> Its more of an implementation detail that completion contributors don't
> work well on dangling nodes, so fix it up for clients rather than
> expecting them to do it themselves.
>
> Change-Id: I3e454734e5b515f4e536f7229d541ca8c6aed60c
> Reviewed-on: https://dart-review.googlesource.com/52645
> Reviewed-by: Paul Berry <paulberry@google.com>
> Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Change-Id: I64a6689f7862fb2d256b348491c79c58ee0fe1a9
Reviewed-on: https://dart-review.googlesource.com/52962
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Deprecate the entryPoint parameter, but still accept it in place of what
used to be (positionally) compilationUnit.
Detect if we have a compilation unit or not; and in the case we don't,
add a new protection by asserting that it has no parent (its the root of
the dangling tree).
Its more of an implementation detail that completion contributors don't
work well on dangling nodes, so fix it up for clients rather than
expecting them to do it themselves.
Change-Id: I3e454734e5b515f4e536f7229d541ca8c6aed60c
Reviewed-on: https://dart-review.googlesource.com/52645
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
The API for pkg/front_end is still in flux so we want to avoid having
any packages depend directly on it (other than analyzer and
back-ends).
This CL re-exports some of the critical pieces of front_end needed by
analyzer clients so that those clients can access them via analyzer,
without having to directly depend on front_end. It also updates
pkg/analyzer_plugin to make use of those re-exports.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2993123002 .
Konstantin Shcheglov