The null assert in `PropertyAccessorElementImpl.variable` is safe
because `ElementBuilder` always creates synthetic
`TopLevelVariableFragmentImpl` or `FieldElementImpl` for a getter or
setter. And the other way around, non-synthetic
`TopLevelVariableFragmentImpl` or `FieldElementImpl` when created
associate itself with synthetic getter / setter.
Change-Id: I40e4ce866edffab6c8bcdf6e408bd1bbfbba6581
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442246
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This fixes a bootstrapping problem: previously we could get into a
situation where the generated files for analyzer diagnostic messages
were out of date, but the code generator for those messages couldn't
be run, because it imported the analyzer itself, which contained
compiled errors due to the generated files being out of date.
There were two problematic dependencies:
- The `GeneratedContent.check` and `GeneratedContent.checkAll` methods
relied on invoking the Dart formatter as a library (rather than
invoking `dart format` as a subprocess); the Dart formatter library
imports the analyzer. Fortunately, this functionality is not needed
by the code generators themselves. It's only needed by the _tests_
that verify that code generation has run. So I was able to break the
dependency by moving this functionality into a new file,
`package:analyzer_utilities/generated_content_check.dart`, which is
imported only by the code generation tests. The new API is slightly
different: `GeneratedContent.checkAll` has been replaced by an
extension method `check` on `Iterable<GeneratedContent>`.
- The diagnostic message code generator used to have a post-processing
step that made use of the scanner to find error messages used by the
parser that needed to be translated, and issued a warning if it
found any. This check was useful a long time ago, when we were
unifying the analyzer and CFE parsers, and is no longer useful, so
I've removed it.
Change-Id: I509b741faca3b9ae21c23936001105ded731b490
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442241
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This fixes an exception that prevents completion from working if a typedef points at a mixin, which is something Flutter has:
```dart
typedef RenderConstrainedLayoutBuilder<LayoutInfoType, ChildType extends RenderObject> =
RenderAbstractLayoutBuilderMixin<LayoutInfoType, ChildType>;
mixin RenderAbstractLayoutBuilderMixin<LayoutInfoType, ChildType extends RenderObject>
on RenderObjectWithChildMixin<ChildType>, RenderObjectWithLayoutCallbackMixin
```
Fixes https://github.com/dart-lang/sdk/issues/61197
Change-Id: Ibf31612d34893f2183a7da513359bdbff6a5c066
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/441962
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This adds support for keywords like `return`, `yield`, `break`, `continue` to Document Highlights. For break/continue, the matching loop keyword (`do`/`while`/`for`) is also highlighted (and this works in both directions). This behaviour matches what I see for TypeScript in VS Code.
This is only supported for LSP because the legacy protocol groups these by "Elements" which we don't have for loops (though since IntelliJ uses its own data for occurrences, it's not clear to me if anyone is using Occurrences over the legacy protocol).
Fixes https://github.com/dart-lang/sdk/issues/61170
Change-Id: I5563ec0a91a6fe33d10a6317d33e9256b3c50209
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442061
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Now every setter after parsing has exactly one required positional
formal parameter. This will cause setter elements have exactly one
formal parameter, and let us avoid checking for it in multiple places.
Remove CompileTimeErrorCode.WRONG_NUMBER_OF_PARAMETERS_FOR_SETTER
Add ParserErrorCode.WRONG_NUMBER_OF_PARAMETERS_FOR_SETTER
Change-Id: I80a6f3f6e51ac2ed2f6ddb49d059c2d78ff64b2e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/441830
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
```
According to Gemini:
There is a very strong and widely followed recommendation.
The formal parameter for a setter in Dart should be named value.
```
So, it makes synthetic setters consistent with manually written setters.
These names sometimes are show in UI, e.g. in hover.
Change-Id: I4b53314aae63dce267906856d98a16ec22d38097
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/441827
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
When the initializer of a variable declaration is exactly a dot shorthand, we can insert the declared type in front of the dot shorthand to ensure that we're retaining the necessary context type.
`E e = .a;` -> `var e = E.a;`
In other cases such as typed literals and constructor invocations, the correction already does what we need it to.
When we're looking at a for-each and the iterable is a typed literal, if there's a dependent dot shorthand, we add explicit type arguments to the literal to retain the context type.
Added tests for the fix and the assist which has the same code path.
Bug: https://github.com/dart-lang/sdk/issues/60957, https://github.com/dart-lang/sdk/issues/60994
Change-Id: I31a05f10a7cdaae731c6f6c59deae12c2543a4a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/441320
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
The exact format of the summary is yet to be decided, but at the moment
it's producing an abbreviated form of Dart that doesn't include function
bodies or documentation comments.
No attempt is made to remove in-line comments, but we might want to
consider doing that.
Change-Id: Iec6e27c54e3099a596d50d5c461356006694690b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/440682
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
This change mainly has side effects for code completion, making sure we're suggesting the right members. When the user writes something like `E e = .^` where `^` is the cursor, they're most likely intending to write a dot shorthand.
So this parser recovery change ensures that we recover as a dot shorthand node and not as a prefixed identifier (missing it's target) in the analyzer. We don't need special casing in the code completion pass to handle dot shorthands in the prefixed identifier visitor now.
The CFE should have no notable changes, but I added a few tests since it uncovered some crashing behavior. The duplicate errors have always been the case even prior to this change.
Bug: https://github.com/dart-lang/sdk/issues/59836
Change-Id: I6c4a9f2c8cc376e4dedd715af76967da471aa681
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/439140
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Significantly improve test coverage of `display_string_builder.dart`.
Fix an error involving a missing space when reading the enclosing
fragment of a local variable declaration.
Change the formatting of `ConstructorElement` to print only the type and
not the name to avoid duplication, as they were the same.
Change the formatting of `TypeAliasElement` to just print the name of
the aliased type, rather than the whole aliased element - as this rarely
provided useful information.
Change-Id: Ie1e4a3649063c2b3662ef7bd21327c17a5b1456b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/441082
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This method wasn't exposed through the analyzer public API, and wasn't
strictly necessary; all it did was wrap up all its arguments (except
the first) in a list and call `formatList`.
In the long term I intend to replace `formatList` with a richer and
more type-safe API that allows clients to supply message parameters
through named parameters. Removing the `format` method now will make
it easier to evolve towards that richer API.
Note that this change is not strictly a no-op; one of the call sites
(in
pkg/analysis_server/lib/src/services/refactoring/legacy/inline_local.dart)
was incorrectly wrapping its argument in a list and then calling
`format`, causing the argument to be wrapped in a second list. That
was clearly a mistake, so I went ahead and fixed it as part of this
CL.
Change-Id: I0796804ab949e66a129bfeec6dfe688dfa113eb2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/440548
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Danny Tuppeny