Previously if a test didn't expect initialize to error (and didn't check for it), the test failure would be hard to diagnose. With this, if you don't explicitly opt-in to allowing failure, an error during initialize will just throw and fail the test.
Change-Id: I01283a70b3571415ec16f2fc4d781c08a953a6a1
Reviewed-on: https://dart-review.googlesource.com/c/94291
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This fixes a mistake where enum classes were resolved to their base types (string, num) before being output in canParse methods of their containing class. This meant for "restricted" enum types (those that should not allow any value), canParse would incorrectly return true for out-of-bound values as long as they were the correct type.
Change-Id: I44e37a60b49287cf7202d5a578ee9c08cf898078
Reviewed-on: https://dart-review.googlesource.com/c/94280
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
When the server fails to start up (writing to stderr) the tests currently would just hang waiting for responses to messages. This will just throw the message as an exception, failing the test with a more useful message, for example:
```
00:07 +0 -1: ServerTest | test_exit_afterShutdown [E]
Analysis Server wrote to stderr:
file:///Users/dantup/Dev/Google/dart-sdk/sdk/third_party/pkg/linter/lib/src/analyzer.dart:106:27: Error: The method 'registerDefault' isn't defined for the class 'Registry'.
- 'Registry' is from 'package:analyzer/src/lint/registry.dart' ('file:///Users/dantup/Dev/Google/dart-sdk/sdk/pkg/analyzer/lib/src/lint/registry.dart').
Try correcting the name to the name of an existing method, or defining a method named 'registerDefault'.
Registry.ruleRegistry.registerDefault(lint);
^^^^^^^^^^^^^^^
```
Change-Id: If64b68b17a0d379f8879891f0346704d4ad360e8
Remove unused imports
Change-Id: I745499f7b038c81320c127410967d939c7756e51
Reviewed-on: https://dart-review.googlesource.com/c/94222
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
Otherwise we'll need to increase the timeout to account for server startup (which will mask if the exit really is taking a longer time than it should).
Change-Id: I5c770efa62dc2a66946fd7a6c07665d3f1b80ee4
Reviewed-on: https://dart-review.googlesource.com/c/94260
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
This tests we can spawn the diagnostic server on-demand. The test was previously marked failing because it needed to be a real inrtegration test.
Change-Id: I52638682d7fb1807584601f7ff933f30b1bd6d70
Reviewed-on: https://dart-review.googlesource.com/c/93949
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
This adds a new server state "shutting down" which rejects requests. The LSP spec says clients should send the shutdown notification, then the exit notification. If an exit notification is received without a shutdown, then the exit code is set to 1.
Change-Id: I50aa186d699a646ee1422f5b3ddaae4bc089b632
Reviewed-on: https://dart-review.googlesource.com/c/93952
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Danny Tuppeny <dantup@google.com>
I'm going to do some refactoring in future CLs that may make some of
these classes and/or methods unnecessary. Making them private will
help highlight when things become unnecessary (because it will allow
dead code hints to be triggered).
Change-Id: I201bf5be0131e69af00789308e17926d98db6f5b
Reviewed-on: https://dart-review.googlesource.com/c/93369
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Rather than have each PotentialModification keep track of its own
source, it's less wasteful to keep track of a map from each source to
a list of the potential modifications for that source.
Change-Id: Ib579f5159100195496a850fbf795b073fc927110
Reviewed-on: https://dart-review.googlesource.com/c/93466
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
If a method parameter is used in unconditional control flow in a way
that a `null` value would directly lead to an exception (i.e. by
dereferencing it, or by passing it to a method that requires a
non-nullable value), this is treated as implying that the method
parameter is intended to be non-nullable.
Change-Id: I4f55e4c95b3cfaee0a2ba9367b47d51083e0b7b1
Reviewed-on: https://dart-review.googlesource.com/c/93363
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
If a named parameter is annotated as `@required`, then this overrides
the NamedNoDefaultParameterHeuristic; the parameter is considered
required regardless of what happens at call sites. A duplicate
`@required` annotation is not inserted.
Change-Id: Ib1385d0a65dd9001bb7abede9de2a319f65a1f86
Reviewed-on: https://dart-review.googlesource.com/c/92844
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Currently assuming that the language team chooses option 2 for
https://github.com/dart-lang/language/issues/156#issuecomment-460525075.
To handle the case where the user does not specify a default value,
and all call sites supply the named parameter, there are two possible
heuristics:
- assumeNullable: mark the parameter as nullable, since the implicit
default is `null`, even though the implicit default is never used.
- assumeRequired: consider the parameter to be `@required`, ensuring
that the implicit default will never be used.
I've provisionally chosen `assumeRequired` as the default behavior.
Functionality not yet implemented:
- If `@required` is already present in the source code, this should
override the heuristic; also it should not be added again.
- If the parameter is already marked as nullable in the source code,
this should override the heuristic.
- Uses of `@required` should be translated to `required`.
- If `@required` is already present in the source code, and a default
value is supplied, the default value should be removed.
- If the parameter is used in a way that demonstrates it was intended
to be non-nullable (i.e. it appears in a place in unconditional
control flow that would cause an exception to be thrown if it was
null), this should override the heuristic and cause it to be marked
as `@required`.
Change-Id: I9f2ec63787fdb6215e6075ecfcc830ed9942b8b5
Reviewed-on: https://dart-review.googlesource.com/c/92532
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Sometimes there is no difference between 'relevance' and 'relevanceBoost',
for example for enum constants. But for primitive constants, there might
be multiple `double` constants, in different libraries with their own
different relevances. And it would be nice to keep relative relevances
of these libraries in primitive type constants.
R=brianwilkerson@google.com
Change-Id: I3641a4709e09f5c5dd979f5ca8df7b0235c708d2
Reviewed-on: https://dart-review.googlesource.com/c/92623
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Danny Tuppeny