Our understanding improved, and out approach changed significantly.
So, this existing implementation is different enough to be not
very useful anymore. And it gets in my way while doing other changes.
Change-Id: If31c20a0a6f86c01a58d16390a989f77962396b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214760
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
We use previously added `CompilationUnitElementImpl.macroGeneratedContent`
to access the current combined content.
In order to make this work with current IntelliJ plugin, without
adding new protocols, we store the generated code into a new file,
and locations for macro-generated elements are in this file.
Locations for elements that are not macro-generated are still
in the source file.
We use `ElementLocationProvider` to separate writing to the file
system, and do this only in DAS.
Change-Id: Ib156c67b0bf1f3474eb06584e76aa532abd597d1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210300
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
In https://dart-review.googlesource.com/c/sdk/+/191862 we added two new
required fields to `Location`. Unfortunately this was a breaking change
because plugins using an older version of the `analyzer_plugin` produce
location objects without those fields, leading to deserialization failures.
This CL makes those fields optional in order to fix the deserialization
issue.
Unfortunately, the `analyzer_plugin` package was published after the
required fields were added. Making them optional is a breaking change
because the constructor parameters go from being positional to being
named parameters.
We also neglected to update the version number of the protocol as part
of the previous CL. Technically this is also a breaking change for clients
of the analysis server, but given that they had no way to test to see
whether these fields existed they would need to have been written as if
the fields were optional in order to reference them at all, so I think
that from a practical standpoint it isn't a breaking change. That does,
however, raise the question of whether we should increment the version
numbers as part of this CL.
Change-Id: I35fc1f8e950669a3d8dd33cee6b81890261b5c47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206942
Reviewed-by: Danny Tuppeny <danny@tuppeny.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This paves the way for allowing analyzer and analysis server clients
to format diagnostic message URLs in a special way (e.g. to make them
clickable).
Note that DiagnosticMessage is part of the public API of the analyzer,
so I've retained the old behavior in a deprecated fashion to avoid
breaking clients that don't yet handle diagnostic messages containing
URLs.
See
https://dart-review.googlesource.com/c/sdk/+/193749/comment/86d1ce4b_77a60b1e/
for additional discussion.
Change-Id: Iae9d43a2be7dbc67cb7cb82afe0a7824043d6113
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196101
Commit-Queue: Paul Berry <paulberry@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 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>
This introduces the new API. When we're happy with this I'll mark the
old APIs as deprecated and fix up the nearly 900 places impacted by the
change.
Change-Id: Ie88e354d9111339dc79448139bd64246cf06e0c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154700
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@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>
Konstantin Shcheglov