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>
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>
Several support classes also had to move to front_end along with the
scanner. Some of these support classes arguably don't belong to the
scanner itself, since they have other uses (e.g. SyntacticEntity,
ErrorCode, ErrorSeverity, ErrorType, and StringUtilities). They will
be reorganized into a more appropriate location in future CLs, at the
time that they become needed by other components of the front end.
In order to avoid dragging in a lot of dependencies, the following
changes were made:
1. Scanner no longer reports errors through Source and
AnalysisErrorListener objects passed to the constructor. Instead, it
provides an abstract reportError() method which clients may override
to perform error reporting in any way they wish. Analyzer contains an
override of Scanner that mimics the old behavior in order to maintain
compatibility.
2. Static members of ErrorCode (`values` and `byUniqueName`) have been
moved to top level, and remain in analyzer. To maintain
compatibility, these static members remain in ErrorCode (as deprecated
members that simply wrap the implementations in analyzer). This means
we have a reverse dependency (front_end depends on analyzer), but this
dependency will go away as soon as we publish the next breaking change
release of analyzer.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/2486873003 .
Mike Fairhurst