(Part of https://github.com/dart-lang/sdk/issues/63288)
This change migrates the packages owned by the developer experience
team to use the new constructor declaration syntax, described in
https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md#abbreviations-of-in-body-constructor-declarations.
This change was performed in an automated fashion, by (a) bumping the
packages' SDK constraints to `3.13.0-0`, (b) enabling the lints
`unnecessary_type_name_in_constructor` and
`unnecessary_const_in_enum_constructor`, (c) fixing the resulting lint
failures using `dart fix`, and then (d) reformatting the affected
files.
To ease code review, I've reverted unrelated formatting changes.
Since this change requires bumping SDK constaints to `3.13.0-0`, it
was only performed on packages that are *not* published on
pub. (Packages that *are* published on pub should remain on lower
language versions until at least after the stable version of 3.13 is
released, so that we don't block users on the stable channel from
receiving updates to those packages.)
Change-Id: Ibb4daebafd239da58251e838ea6a3f336a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505046
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
This sets `useLineEndingsForPlatform=true` for basic completion tests that now pass, but leave it set to `false` in `AbstractCompletionDriverTest` for now because there are a large number of failures in other tests that use that base class due to hard-coded offsets.
It also updates the format tests to support this (plus extracts some helpers to reduce the duplication).
Change-Id: Id2a0323b4605761d05e30bee89f7dccebb1f48c4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/451020
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This adds code to normalize file contents in `PubPackageAnalysisServerTest.newFile()` so all tests using this base class normalize their source newlines by default (this ensures we run with \r\n on Windows, regardless of the git settings always using \n in this repo).
A flag `useLineEndingsForPlatform` allows option out of this, and any tests that currently fail in this mode set this in their setUp - with the exception of a few that were just trivial fixes.
This will make it easier to fix the remaining tests (by looking at code that does `useLineEndingsForPlatform = false`, deleting it, then fixing those tests).
See https://github.com/dart-lang/sdk/issues/60234
Change-Id: If05bc5f7fe3007151c1290831157b6a62d6bf651
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/449880
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This does not remove the computation of available declarations. This CL
seemed big enough without that, so I (or someone else) can get that in
the next CL.
Change-Id: I67ab49b75c8a415ccfaef16c4e49a00026a6091f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341160
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Sorry about the size of the change.
This started as a CL to move the computation of keywords with a record
pattern from the contributor to the pass. In the process of doing so I
realized that the previous computation of the completion node (the node
that's visited) was too aggressive about moving upward in the AST. I
believe the issue happens when we reach a node in a list of similar
nodes (such as a statement in a block).
I changed the computation of the completion node, which necessitated a
lot of changes to existing code. It also resulted in changing several
tests, most for the better I think, but please look carefully for
places where you think the changes aren't reasonable. I'm also
interested in feedback about the change to the computation of the
completion node.
Change-Id: I2c6ac76fe88f672a206c3692d9ff51d2e487ec0e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324620
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
I am concerned about the tests marked with TODOs because I don't know
why the behavior changed. It's possible that the contributor is still
producing the suggestions but that they're being filtered out later.
I checked using the debugger, and they're not in the list of results
that we're getting back, so it seems likely that they represent real
bugs. If we just weren't detecting the bug before then we're good.
But I can't think how rewriting the tests could effect what the user
is seeing, so I think it's safe to make these changes.
Change-Id: If72042b7ec24b97994a12449c811213b8f708f72
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/303000
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
I'm becoming concerned that the filtering is making it difficult to
verify the results. We can look at the textual output to see whether all
of the printed suggestions are valid, but we can't know what other
suggestions are being produced and whether they're valid, nor can we be
sure that suggestions that shouldn't be produced are not being produced.
Change-Id: Id131b9b53740b625ba74a9b5bdb690da21fcdbfc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302901
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This also introduces CompletionResponsePrinter, which I'd like to use
instead of fluent APIs. At some point I decided that using easy to
produce, and easy to update expectations is better. Fluent API based
tests are too magical and require too many helper extensions. Also,
with textual dumps full actual results are visible, so it is easy to
compare them with expectations.
The missing key part for using textual dumps in completion tests, that
I realized only recently, was filtering. So, we don't need to dump
every available type, but we can focus on specifically named, or
specifically filtered, entities.
And configuration for `withX` flags lets us enable including features
that are interesting for a particular test suite.
Change-Id: I4a7f7ec99ed202333cf56cd3bb0dfec9ae5c39f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257261
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Paul Berry