I found a number of places where we need to access `variable3`, so
it might be convenient to have a common interface that provides it.
Still, there are many places where we want to know that this is
specifically `GetterElement`, to separate interfaces for them are
also useful.
Change-Id: Ib671dc3bdb9a04a022fd74921f8ccedcdba79643
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395701
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
We rename `AnalyzerOptions` to `AnalysisFileOptions`, and change it's
comment from "`analyzer` analysis options constants." to avoid anyone
thinking it is specifying options for the `analyzer` section.
Additionally I privatize some of the static values that are only
present for validation - they are not meant to be used outside of
`options.dart`: `AnalyzerSection._trueOrFalse`,
`AnalyzerSection._options`, `AnalyzerSection._strongModeOptions`,
`AnalyzerSection._languageOptions`, `LinterSection._options`.
I also rename `_TopLevelAnalyzerOptionsValidator` to
`_AnalyzerTopLevelOptionsValidator` to align with
`_LinterTopLevelOptionsValidator`.
Change-Id: I4f5735d8bda8edbaf066387b473c05969c3ba7d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395060
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
These utilities are distinct from the base classes like AnalysisRule and
LinterContext. And their import requirements are also distinct. Separating them
in the filesystem should simplify how we slice up the public API.
Change-Id: I365c48c41e5d3db1e3aa649fd70b94cd7da1b069
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395561
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The DTD client requires that the `type` field is populated in DTD responses, but this code previously would omit it when the result was `null` (because it used `result?.runtimeType`).
Change-Id: I5a6e0927e9c02f2abb690aefceca8f8b003cd43b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/394484
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
The theme of this change is that the Registry.ruleRegistry is always
the source of truth for what lint rules are registered, even in tests.
Before this change, there was a mechanism for passing a "rule
provider" around different classes and functions, which is a function
that returns a list of lint rules. This mechanism only existed for one
test, `options_rule_validator_test.dart`.
So this change instead makes that test use Registry.ruleRegistry, and
removes all of the rule provider mechanisms. All in all:
* Remove the LintRuleProvider type alias.
* Remove the LinterRuleOptionsValidator constructor's `provider`
parameter and corresponding field.
* Remove the `provider` parameter from `analyzeAnalysisOptions()`.
* Remove the `provider` parameter from `OptionsFileValidator()`.
* In AbstractAnalysisOptionsTest, remove the `provider` parameter from
`assertErrorsInCode`.
* Rename `_validatePluginsOption` to `_validateLegacyPluginsOption`
while I'm there.
* In order to register the test LintRule classes, they need a proper
`lintCode` property. So create a super class for them, simplifying
each test LintRule class.
Change-Id: Ic153bba006fe0fe2a94abb08ac55723ffb2c356e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393907
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Similar to the previous Hover change that excluded parameter for expressions passed to setters, this does the same for binary operators (where hovering the expression on the right side would also show the parameter info).
Change-Id: I6a2eb0d60ddcc64912b09e7c69bfc44cc700c619
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392940
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This means when we cancel requests ourselves (such as for completion/refactor when another request begins) we can provide more specific codes/reasons.
This change only uses the reason, but when the scheduler is cancelling requests (because of a `/didChange`) it could use the `ContentModified` code preserving existing behaviour where those cancellations are currently handled by the session change.
Change-Id: I48eea55aff08b15a539a1c2c6031598adb4dd069
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/394444
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
I found that the `propagateLinterExceptions` analysis option was
being passed to the AnalysisRuleExceptionHandler class at
approximately the same point where the exception handler is called, and
also that the AnalysisRuleExceptionHandler class's `logException`
method did not _use_ the `propagateLinterExceptions` value; it just
_unconditionally_ returned it. So it gave it back to nearly the same
code that passed it in.
So we can simplify all of this by removing the `propagateExceptions`
field in AnalysisRuleExceptionHandler. But then that class has zero
fields and one method. _And_ that one method is _the only_ ,method
that is ever passed in to AnalysisRuleVisitor as the exception
handler. So remove the class altogether, and inline the method in
AnalysisRuleVisitor.
AnalysisRuleVisitor instead takes the bool value,
`shouldPropagateExceptions`, and does the right thing with it.
Additionally:
* Privatize AnalysisRuleVisitor `registry` property.
* Make AnalysisOptionsImpl `propagateLinterExceptions` property final.
Change-Id: Ia438881a3eccb3e26ebed294a7b7b8329d7961ed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393902
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
The lints `omit_obvious_property_types` and
`specify_nonobvious_property_types` previously had error fix status
'needsEvaluation'. This CL changes it to 'hasFix'. This is needed in
order to get access to the fix in IntelliJ.
This CL also corrects a bug whereby a map literal was considered to have an obvious type in cases where there were no actual type arguments and no elements with an obvious type.
Change-Id: Id9305152d086604b78636b696bd97e318ed6bdb5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393280
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Keerti Parthasarathy