The AST refactor for "UI as code" left behind a few things whose names
ended in "2". This CL deprecates those things and creates
replacements that don't end in "2", so that we keep the API clean. In
a future breaking change release of the analyzer we'll remove the
deprecated things.
The following methods and classes are added:
- ForStatement and ForStatementImpl
- ListLiteral.elements
- SetOrMapLiteral.elements
- AstVisitor.visitForStatement
- AstFactory.forStatement
- NodeLintRegistry.addForStatement
The following methods and classes are deprecated:
- ForStatement2 and ForStatement2Impl
- ListLiteral.elements2
- SetOrMapLiteral.elements2
- AstVisitor.visitForStatement2
- AstFactory.forStatement2
- NodeLintRegistry.addForStatement2
In a similar way to how we did the previous stage of AST migration,
the existing visitors have been modified so that the default
implementation of visitForStatement2 redirects to visitForStatement;
this allows clients to change their overrides of visitForStatement2 to
override visitForStatement instead. Once all clients have been
migrated we will be able to delete the visitForStatement2 method.
Change-Id: Ife5949071fe4cb50791cd4f2f4b99a1bfaad54c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97360
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is a breaking change, however clients that switched to using
`Expression.precedence2` (which was introduced in analyzer release
0.35.3) are unaffected. After this change, clients may switch back to
using `Expression.precedence`.
Change-Id: Ia952c44001bdea91d32082add0be7e10c9936181
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/94000
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This constitutes a breaking change, so the analyzer major version
number is bumped to 36. Clients that have stopped using the removed
data structures (and the methods associated with them) should be
unaffected.
Change-Id: Iab68ecf8d10a13013ebb6b1198c54755225d0eb7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95704
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
- ForStatement and ForEachStatement will be replaced by ForStatement2.
- MapLiteral and SetLiteral will be replaced by SetOrMapLiteral.
To ease the transition, the old classes are subtypes of the new
classes, so even though the analyzer still creates instances of the
old classes, clients should be able to start referring to the new
classes in their code. The analyzer will stop creating instances of
MapLiteral and SetLiteral when the experimental flags for the "UI as
code" feature are turned on, and will stop creating instances of all 4
classes when we bump the major version number (which should happen
sometime in March).
For visitors, we've updated the base classes with the following default methods:
visitForStatement(node) => visitForStatement2(node);
visitForEachStatement(node) => visitForStatement2(node);
visitMapLiteral(node) => visitSetOrMapLiteral(node);
visitSetLiteral(node) => visitSetOrMapLiteral(node);
So clients should be able to start revising their visitors to override
the new visit methods rather than the old ones, and the visit methods
in the base classes will automatically forward to the new visit
methods.
Change-Id: Ifde3a2aa3c8c49ce4e65dfaabf086db4dabb73f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95665
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The following AST node types will be deprecated soon:
- ForEachStatement (use ForStatement2 instead)
- ForStatement (use ForStatement2 instead)
- MapLiteral (use SetOrMapLiteral instead)
- SetLiteral (use SetOrMapLiteral instead)
To allow clients to stop implementing visit methods that accept these
AST node types, we add a default implementation of each corresponding
visit method to each of the analyzer's visitor base classes; these
default implementations forwards to the new visit method.
This frees clients to begin migrating their visitors to the new AST
node types.
Future CLs will deprecate, and later remove, the old AST node types.
Change-Id: I8d86b64ef0b131012f0a9959aa8940e0d8561485
Reviewed-on: https://dart-review.googlesource.com/c/94301
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Several places in the analyzer and the analysis server were using
hardcoded integers to represent precedence, rather than referring to
constants defined in the front_end. This led to some subtle
off-by-one errors, because the old analyzer convention (prior to
integration with the front_end parser) used 0 to represent the lowest
precedence of an expression (and -1000 to represent the precedence of
non-expressions), whereas the front_end convention is for 1 to
represent the lowest precedence of an expression. As far as I can
tell there was no user visible impact, but it made it very difficult
to reason about operator precedence.
This CL updates the analyzer and the analysis server so that they
don't hardcode any precedence values; instead they refer to named
constants in the front end.
In a follow-up CL I'll reduce some hardcoded precedence numbers in the
front end itself.
Change-Id: Id3869afeb83042cc7d6630a0a4a0533a07058736
Reviewed-on: https://dart-review.googlesource.com/c/93964
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Example code:
```dart
import 'package:meta/meta.dart';
class A {
@literal
const A();
@literal
const A.named();
}
var a = A();
var b = const A();
const c = A();
var d = new A();
var e = new A.named();
```
Produces:
Analyzing b.dart...
hint • This instance creation must be 'const', because the A constructor is marked as '@literal' at b.dart:11:9 • non_const_call_to_literal_constructor
hint • This instance creation must be 'const', because the A constructor is marked as '@literal' at b.dart:14:9 • non_const_call_to_literal_constructor
hint • This instance creation must be 'const', because the A.named constructor is marked as '@literal' at b.dart:16:9 • non_const_call_to_literal_constructor
3 hints found.
Bug: https://github.com/dart-lang/sdk/issues/34259
Change-Id: Iba10e5e0a0b2d0f7e99556cd6c201cea229ad675
Reviewed-on: https://dart-review.googlesource.com/c/88422
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
The API change requires adding a "context" parameter to
NodeLintRule.registerNodeProcessors. If we did this naively it would
be a breaking change since the existing linter code overrides this
method with an implementation that doesn't accept such a parameter.
So to avoid making this a breaking change, we introduce a new
interface NodeLintRuleWithContext that extends NodeLintRule, and adds
the context to the registerNodeProcessors method as an optional
parameter. The analyzer will only pass in the new parameter if the
lint rule implements the new interface; otherwise it will call the
method in the old way. This will allow the linter to be migrated to
use the new API at its pace.
The next breaking change version of the analyzer will change both
NodeLintRule and NodeLintRuleWithContext so that the context parameter
is required, and will pass in a context unconditionally. At a later
date, after the linter has been fully migrated to the new analyzer
version, we will be able to switch back to NodeLintRule and deprecate
NodeLintRuleWithContext.
Change-Id: I75ada0e94e26f831d6f2cb82cddfa706100eb185
Reviewed-on: https://dart-review.googlesource.com/c/82522
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Paul Berry