This prevents inline values showing up alongside code that didn't execute in conditional blocks. It does also mean they don't know up in conditional blocks that _did_ execute one execution has fallen out of them, but I believe this is the best we can do with the current LSP APIs (unless we try to track execution across requests, but that would probably be complete and not entirely reliable).
Fixes https://github.com/Dart-Code/Dart-Code/issues/5454
Change-Id: Ia1cf2437b76844ff0a6aeeb958d769c9523dc5dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433200
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This is a partial revert of ca9523058e (it removes the behaviour change and the test that verifies this, but leaves two additional tests that were added relating to roots that are created later).
If we rebuild contexts when a root is deleted, we may get stuck in a loop because we will again try to recreate the same (deleted) root, and then the watcher will close in a way that looks like a deleted folder, and we will repeat.
Fixes https://github.com/dart-lang/sdk/issues/60863
Change-Id: I10289160b341d273e8e409184a1c013c7fb9439d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433140
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
For https://github.com/Dart-Code/Dart-Code/issues/4729 we added a configuration setting to let you control how much documentation was included in responses. The motivation here was to reduce the completion payload sizes when running in remote workspaces (Dart-Code would adjust the default setting if not explicitly set by the user based on the workspace kind).
However in hindsight, forcing no docs on Hovers just because we didn't want them in Completion requests was a bad choice, because these are individual requests where the payload size is less important and seeing the docs is useful.
So this alters the setting to accept a `Map` to allow you to have different preferences for each request that returns docs. Dart-Code will be updated to adjust the defaults accordingly (after this lands) so that Hover/SignatureHelp can default to `"full"` even in remote workspaces.
Work towards https://github.com/Dart-Code/Dart-Code/issues/5499
Change-Id: Ib64f762a0559c7afc7653fad9749fc208beee8b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431280
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This is a big CL; no code is really "changed." We basically move 3
components into the public API, which can all be reviewed concisely
in the `api.txt` file.
* The AnalysisRule classes: `AbstractAnalysisRule` (which is good to
make public as a lot of the public API is specified and documented
here), `AnalysisRule`, `MultiAnalysisRule`.
* The Pubspec classes, available for linting pubspec files:
`PubspecDependency`, `PubspecDependencyList`, `PubspecEntry`,
`PubspecEnvironment`, `PubspecGitRepo`, `PubspecHost`, `PubspecNode`,
`PubspecNodeList`, `PubspecVisitor`.
* The `RuleVisitorRegistry` class. This class is needed by analysis
rule authors, and is part of the public API of AnalysisRule.
Change-Id: Ib1803180de9469f4ff39cf1778f96787f5f74b14
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432363
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This changed definition is required for google3, in order to support
using `WorkspacePackage.isInTestDirectory` over the `inTestDir`
extension getter.
Then remove linter's export of the `inTestDir` extension method, and
instead rely on WorkspacePackage in lint rules.
Change-Id: I81fc6a27ca8f19f71a8b915edb3968d5d43262ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431943
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
I moved several classes out of `diagnostics.dart` into their own
libraries under `pages`. I also moved one of the singling files into
`pages`. Several other sibling pages were moved to `utilities`. In the
process I needed to make a couple of methods public rather than private.
There are no functional changes.
I was going to split out the rest of the classes from `diagnostics.dart`
and `pages.dart` but I haven't yet decided whether they should all go
into a single directory or whether they should be in two directories.
The classes in `pages.dart` appear to be classes appropriate for any
web site generating code while those in `diagnostics.dart` are specific
to this web site, but it isn't clear to me that the abstraction is
helpful given that we only have one web site to build.
Change-Id: Iff968bc3bfb654db24e896cb1ae0ced9bc6333fd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432360
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This normalizes the names of the classes to match the label displayed to
the user (to make it easier to find the class that needs to be updated).
It also normalizes capitalization in titles and the formation of the
page ids.
This is a precursor to splitting the page classes out into separate files.
Change-Id: I571bfaf23057f2366274e4b853412c8756151f65
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432121
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This adds a new page to the diagnostic pages that displays the current
state of the message scheduler (or rather the messages passing through
the scheduler) as well as the most recent history.
The next steps after this are to
- include this information (and library cycle information) in the
generated report
- add this (and cycle) information to the analytics we're gathering
I put the new page in its own file, and would like to move existing
pages to separate files as well. Doing so might trigger moving some
files around in the directory structure in order to better organize
the code.
Change-Id: Ic4f0e72ffbadc1e39702f1f8f13850f5bd5814a5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431947
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
For the analyzer plugin APIs, these classes should not have the word
'Lint' in them, as they are used for all analysis rules, whether they
report lints or warnings.
* LinterContext -> RuleContext
* LinterContextWithParsedResults -> RuleContextWithParsedResults
* LinterContextWithResolvedResults -> RuleContextWithResolvedResults
* LintRuleUnitContext -> RuleUnitContext
I'm open to better names for these. Some of these suffer from a
chain-of-nouns name (a "RuleUnitContext" is a Context for a Unit for
a Rule). So we could go with "UnitContextForRule" and "ContextForRule"
or other ideas like that.
Only RuleContext and RuleUnitContext will be public API.
Change-Id: I5550736beaba7e39b36e7b5584ca6d023aa4d02b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431703
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL contains no functional differences; it just reorganizes the code.
I expect to be adding data to the collected report, and I decided that
it would be better to break the massive method up before doing so in
order to improve overall readability.
I also wondered whether we might want to structure the data in a similar
way. For example, the top-level map could have entries corresponding to
each of these methods, each of which has a value that is a map
containing the data collected by that method. I don't know whether this
would make the output easier to read or whether the current form is
depended on anywhere, but it's something to consider for the future.
Change-Id: Id0ef3c2f64b00ea58069c496e7c485c7b3f163c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430560
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This CL contains breaking changes for package:dtd and prepares both package:dart_service_protocol_shared and package:dtd for publish.
This CL also fixes https://github.com/dart-lang/sdk/issues/60757 so that DTD-registered services are sent over the `Service` stream upon initial subscription like what is done for client-registered services.
Change-Id: I619af816e64af01864c7ed9b98743c6691bf7e0b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429161
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Kenzie Davisson <kenzieschmoll@google.com>
Brian Wilkerson