The previous CL changes from just replacing paths, to handling URIs + filePaths separately.
This updates the committed scenario files so:
`file://{{workspaceFolder-0}}` becomes just `{{workspaceFolder-0}}` (since this token implies the file URI), and `{{workspaceFolder-0}}` (without the prefix) becomes `{{workspaceFolder-0:filePath}}` (to signify it was a file path).
Even with these changes, they fail for different reasons (invalid git hashes, mismatches in expected vs actual requests) so I there is still more work to do here.
Change-Id: Ic1543ab96ca002073540ef034adecb4c9ea57e58
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501521
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
For posix paths, replacing the file path during normalization and then swapping it back later works for both paths and URIs, because a file URI just contains the file path verbatim:
file:///foo/bar/baz
However that's not the case for Windows:
C:\foo\bar\baz
file:///c:/foo/bar/baz
So when normalizing, we need to know if we normalized a URI or a file path, so that we can reverse it later.
With this change, we'll use `{{workspaceFolder-0}}` for the URI, and `{{workspaceFolder-0:filePath}}` for the file path. Then when reversing, we can easily put the correct one back.
This also updates the log replace/scenarios to use the LogNormalizer to perform the denormalization so they don't have to have duplicated logic about what to restore.
I've also updated the existing committed scenarios (EDIT: moved this to a separate CL because Gerrit is falling over) - although even with those changes, they all fail for different reasons (invalid git hashes, mismatches in expected vs actual requests) so I think there is still more work to do here.
Fixes https://github.com/dart-lang/sdk/issues/63330
Change-Id: Ib4c4aabe2c7c0d089bd620bdf00de37acde25f52
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501600
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This some basic scaffolding for the migrate tool. We'll add a protocol to the analysis server with the following parameters and result:
Parameters
- `uris`: Workspaces/packages to be migrated
Result
- `summary`: Information about fixes that could not be applied automatically. (e.g. if there was a conflict) or information about what fixes were applied and what SDK version the pubspec has been changed to.
- `edit`: A list of edits to be applied.
There are no interesting tests yet, but I hope to have a suite of tests for the next change.
Fixes: https://github.com/dart-lang/sdk/issues/63247
Change-Id: I77508720acb17af5ec86675fd3f3045e2a610bf2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496801
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
The Flutter Widget Preview feature is currently implemented within
Flutter Tools, which is responsible for detecting widget preview
annotations in the user's project. When previews are detected, the
Flutter Tool injects code generated based on the detected previews into an artificial widget_preview_scaffold project and performs a hot reload to render updates to the preview set in the scaffold application.
`package:analyzer` is currently being used to detect previews, but this comes with a significant amount of memory overhead. Since widget
previews are mostly being used from within IDEs which already have an
active analysis server, moving widget preview detection into the DAS
will remove the need for creating an additional analysis context in the Flutter Tool itself.
This change includes the initial work to move widget preview detection
into the DAS. It utilizes a pull-based mechanism, where the Flutter Tool listens for file system events and then queries the DAS using the `dart/textDocument/getFlutterWidgetPreviews` and `dart/workspace/getFlutterWidgetPreviews` LSP methods.
Each reported preview contains some generated code based on the annotation used to define the preview. This code has all constants from the original annotation evaluated to either primitive values or constant expressions with namespaces applied to each symbol, allowing for the Flutter Tool to inject this code directly when updating the generated code in the scaffold project.
Towards https://github.com/flutter/flutter/issues/179584
Change-Id: I043cb3235a66b25dda3f852ca7f147bff0e1e537
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478100
Auto-Submit: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The `Match.operator[]` does the same thing and is
generally recommended (and shorter).
(I want to deprecate `group` and `groups`)
Tested: Refactoring.
CoreLibraryReviewExempt: Calling equivalent function.
Change-Id: I4c758968ae622fe16b7322be1b29b05b91e7fcd9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489021
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Add `ClassBody.members` and `EnumBody.constants`/`members` so callers
can access class and enum contents through the common body interfaces
instead of pattern matching on `BlockClassBody` and `BlockEnumBody`.
Implement empty node lists for empty class and enum bodies, update the
public API, and migrate analyzer, analysis_server, analyzer_plugin, and
linter code to use the new accessors directly. This removes the ad hoc
`members2` helper extensions and a large amount of repeated `tryCast`
and `switch` logic, making body traversal more uniform.
Change-Id: I51d75f2253c7e6f75efecae84bf0443ff5eb6788
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/488263
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Work towards https://github.com/dart-lang/sdk/issues/61868
This adds a new notification type, 'PluginPrint'. There are several
fields and variables then named 'pluginPrint' or 'print', and I am
definitely open to changing these names, but this is the best one that
I thought of.
PluginPrint has three fields: The name of the plugin that printed, the
message that was printed, and the timestamp.
We wrap each plugin's AnalysisRule invocations with a zone, so that
the `print` handler can know the name of the plugin. The prints are
caught and sent to the server isolate as Notifications. The
PluginIsolate then stores the collected prints. The Plugins Insights
page can then retrieve them and display them.
Manual testing, with 1000 libraries that get new lint reported once per
file, I did not observe a negative performance impact.
Change-Id: Id800ae41781c15ce89d06b563878c2b0edae43d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/486827
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This copies much of the logic from the normalize.dart standalone script.
It normalizes "workspace folders," context roots, and the Dart SDK path.
I tweaked the SessionLogger constructor to instantiate its own
`SessionLoggerInMemorySink` rather than the caller needing to call it.
And then the `SessionLoggerInMemorySink` instantiates the
`SessionLoggerFileSink` so that the caller doesn't need to worry about that. This lets the sink and the nextLogger each be final, and removes
details about what I consider "SessionLogger implementation details"
from the caller's concern.
When a SessionLogger is instantiated, it creates a LogNormalizer which
the SessionLoggerSinks use to normalize log entries.
I almost used
`WorkspacePackage.packagesAvailableTo(String libraryPath)`, but it
seemed unnecessary to require a file path (there is a TODO about
considering files in/out of the 'lib' folder, but not necessary for this
work). So I made `Workspace.packages`, as most of the subclasses
already implemented this concept.
Bug: https://github.com/dart-lang/sdk/issues/62697
Change-Id: Ic57fec490414cef7028c290614363623e88f5c15
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/485260
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is the first CL in what will probably turn out to be a fairly large
number of CLs. The goal is to get the relevance table generator up to
date so that we could then use it to generate new tables, thereby,
hopefully, improving the ranking of completion suggestions.
It includes two sets of changes, and if it would be easier to review I
can split it into two CLs.
The first set of changes is to add visit methods for all of the AST
node classes. While the use of a recursive visitor doesn't allow the
compiler to let us know about missing visit methods, I temporarily
changed the superclass in order to ensure that all of them are
overridden. I want to do that so that we can know when a lack of data
collection is intentional vs. just an oversight.
Which is where the second set of changes comes in. This adds a
mechanism to report if the generator ever sees a keyword or identifier
for which data should have been collected but wasn't. It does this by
recording all such tokens before visiting the AST, and then removing
tokens for which data is collected and tokens that we've explicitly
decided we didn't need data for.
In future CLs I want to get it to a place where we can validate that
the generator and the code completion passes are using the same set of
keys for the generated tables. I also want to add reporting if we have
failed to record data for an expected key because that would indicate
that the corpus used to build the tables is incomplete in its coverate.
Change-Id: I9cb4b729f558884e7321abd741e7b8dc85c997ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/486260
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
My previous CL made some LSP tests run with String IDs instead of ints, but those tests don't appear to go through the session logger so did not fail with the casts here.
This change adds a base integration test that also uses string IDs, which did fail on the cast, so I've updated the session logger to use `Either2<int, String>` for IDs instead.
Fixes https://github.com/dart-lang/sdk/issues/62442
Change-Id: Iee582e9ce2b8b5a1127120c987670a679d2ca76c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/473260
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I don't have a lot of confidence that the data being collected is what
needs to be collected in each of these cases, but I believe that I've
correctly identified the visit methods that need to be collecting data.
I think we need to have a test that ensures that the keys being used in
this table generator are the same as the keys being used by the
relevance feature computer (as computed by the in-scope pass). I don't
know exactly what that test would look like, but that would ensure that
(a) the keys are the same and (b) the table generator isn't missing
keys being used by the completion engine or collecting data that isn't
being used.
I also fixed a bug that prevented this generator from running and tested
to ensure that it could run over several example packages.
Change-Id: I0c0cff148d288942e39ee876e89cdf9d1468f59d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/473780
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This still isn't complete. It only removes file changes when a file is
closed and it ought to remove them when a file is saved, but I think
this is a minor enough hole that we can land this now and work on it
later.
It also still doesn't handle the legacy protocol.
Change-Id: If07d20fe61cc3d03167f9a930b67ddd59b8e97e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471860
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Previously, the result of calling `toJson()` could still include some classes (like `List` and `EitherX<>` unions). This didn't cause issues because `jsonEncode()` would handle those types anyway (calling `toJson()` recursively), however changes to support the log replay are looking inside the returned Map and should see consistent types.
Change-Id: Ie52a7251ee10579de8ce605584feb82abc15eb8d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/472900
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
- Return messages that fail to parse with the error response.
- Add support for open subdirs to projects, speeds up SDK replays.
- Fix up normalize script when package deps are subdirs of the project.
- Re-record the sdk scenario with only pkgs/analysis_server open.
- Fix some bad hard coded responses that were failing to parse.
- Add extra context (extra messages recieved) when scenarios fail.
Change-Id: Idfdcde70776967c2d419e76a21a6c6d1c59902f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/472700
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
- Adds support for normalizing package dependency roots using the
package config
- Updates the project generator so it can handle multiple project roots
and analysis contexts, as well as package configs.
- Handle sending watcher messages to the analyzer.
Removes the basic "initialization" scenario that didn't have any real
value other than being an example github project scenario.
Change-Id: I5b49effe524d325360a754296f4cc3578ad49527
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471360
Commit-Queue: Jake Macdonald <jakemac@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
- Skip notifications from analyzer
- Hard code responses to certain startup logs if they are unexpected
- Use cli_util to show loading spinner and get sdk location
- Update normalize to substitute the sdk location
- Make id field optional on message (notifications don't have ids)
Change-Id: Ia5276eef554a3afefeae227fa7351f902d21131e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471060
Auto-Submit: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Runs either `dart pub get` or `gclient sync`, based on project type.
For the SDK, copies the .gclient and .gclient_entries files as well
into the parent dir.
Also adds a `--timeout` argument, controls how long to wait for analyzer messages.
Change-Id: Id2c28e6d0251e94914bb0650be104c1f90a66651
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468620
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
This will allow diagnostic reporting code in the analyzer to be more
easily converted to the new literate diagnostic reporting API, because
it will make it possible to use `SourceRange` as the common
denominator for situations where the location where a diagnostic needs
to be reported might come from either a `SyntacticEntity` or a
`SourceRange`.
Change-Id: I6a6a6964f3ec2ea33e8900d93b5abe714c9e1dcc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467682
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the logic in `pkg/analysis_server` to use
`DiagnosticCode.lowerCaseName` instead of `DiagnosticCode.name`, and
`DiagnosticCode.lowerCaseUniqueName` instead of
`DiagnosticCode.uniqueName`. This ensures that diagnostic codes are
matched in a case-insensitive fashion.
This paves the way for deprecating (and eventually removing) the
`DiagnosticCode.name` and `DiagnosticCode.uniqueName` getters.
Change-Id: I6a6a69643ef19385ab43d7a04809e58305ca4f0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466185
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This paves the way for a follow-up CL that will standardize all
diagnostic names to `lower_snake_case` conventions.
For now, the case differences between the entries in
`error_fix_status.yaml` and the actual diagnostic code names are
accounted for by adding some calls to `.toLowerCase()` to
`verify_error_fix_status.dart`.
Change-Id: I6a6a6964b0eacf50b11f302ab511fba149b1ac07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465981
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Modifies the code generation logic that populates the
`DiagnosticCode.uniqueName` field so that it doesn't include the
diagnostic's class name.
This paves the way for removing the last remenants of the diagnostic
classes from the analyzer.
Change-Id: I6a6a696453fe1f2bd8bd3cea00a9a496392fbf98
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464240
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Setting the command-line arguments separately from the protocol used to
be necessary, but it no long is, so it's cleaner to just set the command
line arguments when creating the server and moving the handling of the
protocol option into the server. This resulted in a cleaner API and
implementation.
Change-Id: I9456e2a43310bb855b54c010af64ce0328a08ff7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464785
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Danny Tuppeny