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>
The previous three scripts had some redundancies:
* Both the flutter/flutter analyzing script and the flutter/packages
analyzing script checked out flutter/flutter. Combining them saves
several minutes.
* The script that analyzed flutter/engine was pointing to the old
engine repo, which was archived months ago. In pointing the script
to the new sources at flutter/flutter, this would introduce another
instance of cloning flutter/flutter. Combining this with the other
scripts saves several minutes.
The only other little changes to the code are the introduction of
more echo commands, more `pushd`/`popd` vs `cd`, and isolating the
three tasks into functions for readability.
Change-Id: I08414d824c25075a8810b1aa0cc299c64328abbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432881
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Ryan Macnak <rmacnak@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>
When an `is` test is trivially satisfied (i.e. `expr is T`, when the
static type of `expr` is a subtype of `T`), the `is` test is
guaranteed by soundness to evaluate to `true`, so any code path that
follows from the `is` test evaluating to `false` is unreachable.
This reasoning wasn't valid prior to sound null safety, because in
mixed mode programs, it was possible for an expression to evaluate to
`null` even if its static type wasn't nullable, and hence `expr is T`
might evaluate to `false` even if the static type of `expr` was a
subtype of `T`. So this change is gated on the `sound-flow-analysis`
language flag (which is enabled in Dart 3.9).
Fixes https://github.com/dart-lang/sdk/issues/60718.
Change-Id: I66a65580b738162f23b6fb468b71fcac66bfbb95
Bug: https://github.com/dart-lang/sdk/issues/60718
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431740
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Write barrier elimination applies when there is no potential Dart call between a StoreFieldInstr and an AllocateObjectInstr. But the control flow between all potentially throwing instructions in a try block and the corresponding catch block is not explicitly repreresented in the flow graph, so the writer barrier elimination pass needs to handle catch entries specially.
TEST=vm/dart/write_barrier_catch_entry_test
Bug: https://github.com/dart-lang/sdk/issues/60836
Change-Id: I96d5999433320e87da095f85e4a7438bcf5e134f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432880
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
During the implementation of flow analysis for patterns, I added a
hack to the flow analysis tests so that all variable declarations were
desugared into the equivalent pattern variable declaration. This had
the advantage of getting some extra testing "for free" during early
development of the patterns feature, but it had a few disadvantages:
- It the caused the shared flow analysis and type inference tests to
stop exercising flow analysis code paths for ordinary variable
declarations.
- It forced the testing logic to "support" pattern variable
declarations that are late or lack an initializer; these are things
that regular Dart doesn't support, and they made the implementation
of `PatternVariableDeclaration.visit` much more complicated than it
needed to be.
The language team is currently contemplating some changes to how
promotions work in ordinary variable declarations and pattern variable
declarations (see, for example,
https://github.com/dart-lang/language/issues/4347#issuecomment-2861859329). So
in order to be able to experiment with these possibilities, I want to
get rid of this hack.
This CL adds a `VariableDeclaration` class, to represent ordinary
variable declarations, and modifies the `declare` function (which is
used by tests for creating an ordinary variable declaration) so that
it creates a `VariableDeclaration`, rather than rewriting it into a
`PatternVariableDeclaration` containing a `VariablePattern`. It
removes "support" for testing pattern variable declarations that are
late or lack an initializer, simplifying
`PatternVariableDeclaration.visit`.
A few test cases in `type_inference_test.dart` were checking the
generated IR for ordinary variable declarations, verifying that it was
properly desugared into a pattern variable declaration; these
expectations have accordingly changed to no longer expect desugaring.
There is no functional change to the compiler or analyzer
toolchain. These changes only affect tests in
`pkg/_fe_analyzer_shared/test`.
Change-Id: I90f074cd6e7a6ed5ed11afadeadb6131ce1d282f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432122
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The following renames are performed:
- The class `Declare` (which is the "mini-AST" representation of a
pattern variable declaration), is renamed to
`PatternVariableDeclaration`.
- The top level function `match` (which is used in tests to construct
a "mini-AST" representation of a pattern variable declaration), is
renamed to `patternVariableDeclaration`.
The new names should help avoid confusion in a follow-up CL I intend
to create, which will introduce a new `VariableDeclaration` class to
represent ordinary variable declarations.
There is no functional change. These renames only affect tests in
`pkg/_fe_analyzer_shared`.
Change-Id: Ic6b6f75cbb312180273a08f2c3926f83da254bc0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432120
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, when assiging to a local variable that was promoted, if
the newly assigned value was not compatible with any of the promotions
(i.e., the variable was fully demoted back to its declared type), then
the set of types of interest was cleared.
This behavior was not documented anywhere in the spec, and it seems
oddly inconsistent to me; as far as I can tell, flow analysis doesn't
clear types of interest in any other circumstances. I've looked
through git history as well as my personal notes, and I've been unable
to find any justification for this behavior. So, with the agreement of
the language team, I'm removing it when sound-flow-analysis is
enabled.
Fixes https://github.com/dart-lang/language/issues/4380.
Bug: https://github.com/dart-lang/language/issues/4380
Change-Id: Ic1ca80a61e21482e659afa8796b08fce707db3c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429227
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The current conditions make it so that every library transitively reachable from a reload target (and therefore included in the DDC output) must be known in the client when `dartDevEmbedder.hotReload` is called.
While this is the case for pages running with DWDS, it's an unnecessary constraint. Some users may only care about reloading a specific subset of known libraries. As is the case in dart-pad when we only need to reload the main library as we know this is the only code that can have changed.
Any new libraries must also registered and initialized as this is new code not yet in the page. This would happen if a new import was added to the code.
Change-Id: I164f59a6931fd809867716c164cb467880806f8c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432440
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
These exports make it too easy to accidentally rely on private
analyzer impl. Where it is necessary, calling out the individual
imports helps to understand where private impl is used.
Change-Id: I2968610d8285812087b3f716159003d12561eb30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432460
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>
Devon Carew