This change was generated by the following process:
- The script `pkg/analyzer/tool/messages/rename_error_constants.dart`
was run. This generated the vast majority of the diffs.
- Then all modified files were reformatted using
`tools/sdk/dart-sdk/bin/dart/format`.
- Finally, the script `pkg/analyzer/tool/messages/generate.dart` was
run, to rebuild generated code.
Change-Id: I6a6a69644ed8740ad6269d98cb169076151824ed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/444921
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Until recently, everything in rule_context.dart was found in
linter.dart. That file was broken up [1]. That file previously had a
lot of exports; it was a sort of barrel file for lint rules. In order
to make that change "minimal," (it was still huge), I retained some of
the exports. Now we're in the process of removing those exports.
In this change, I remove the exports for `rule_state.dart` and `linter_visitor.dart`. This doesn't affect too many files.
[1]: https://github.com/dart-lang/sdk/commit/438b560e44659cebf73bccba3ecf968806477c5c
Change-Id: I83110b22a07186560f6c853f033e070ac050ecd1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445123
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The following classes are moved from `package:analyzer` to
`package:_fe_analyzer_shared`:
- `Diagnostic`
- `DiagnosticMessage`
- `DiagnosticMessageImpl`
The following declarations are also moved, since they are needed by
the above classes:
- `formatList`
- `Severity`
- `Source`
- `TimestampedData`
There is no change to the analyzer public API, and `export`
declarations have been added to the analyzer libraries that the
declarations have been moved from, so that code depending on these
declarations is unaffected.
These changes are part of a larger arc of work that introduces methods
`.withArguments` and `.at`, forming a literate API for reporting
analyzer errors that looks roughly like this:
diagnosticReporter.reportError(
ERROR_CODE.withArguments(...arguments...).at(...location...));
Moving this code into `_fe_analyzer_shared` is necessary because
scanner error codes are defined inside `_fe_analyzer_shared` (to allow
the scanner to be shared between the analyzer and CFE). Hence, to
avoid a circular depedency between `_fe_analyzer_shared` and
`analyzer`, the `.withArguments` and `.at` methods will need to live
in `_fe_analyzer_shared` too, as well as the classes representing the
diagnostic messages they create.
Note that there are some minor changes to
`pkg/analysis_server_plugin/api.txt` and
`pkg/analyzer_plugin/api.txt`; these have to do with the way the
`api.txt` generator chooses to report referenced elements, and don't
reflect actual API changes.
Change-Id: I6a6a6964a5c46f4a0205ce0d85620669ce55eb3c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/444620
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This library mostly exports _public_ API, and the to-be-deprecated
NodeLintRegistry class. So we just move private RuleContext classes
into a new library, and remove the exports.
The lint rules then are adjusted, mostly just renaming
NodeLintRegistry -> RuleVisitorRegistry. But also, this removes a lot
of implementation imports; most rules now have _no_ private imports!
Change-Id: I023f7efa979f94d208a6ae7421902145e8761c9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/443364
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Because ChangeBuilder can be used to modify multiple files, the EOL should come from an individual files edit builder and not from the overall ChangeBuilder.
This change renames `eol` on ChangeBuilder to `defaultEol` (since it's still useful to supply a custom default, for example when moving a class from an existing file to a new file, we want to default to the same EOL as the source file), and adds an EOL to file edit builders which is computed from the file content (and falls back to the default from ChangeBuilder if there are none).
My intention here is to not introduce any breaking changes (yet) so the ChangeBuilder constructor interface still has the "eol" named parameter (marked as deprecated) as well as the new `defaultEol` parameter.
I added a new `StringExtension` for `endOfLine` to both analyzer_plugin and analysis_server_plugin as we need this in both places (but I expect one of those projects will ultimately be dropped). This slightly differs from `CorrectionUtils.endOfLine` because it can return `null` which is a signal to fall back to the ChangeBuilder default instead of forcing its own default. (CorrectionUtils.endOfLine now uses that extension, although because of the null/default, it's likely that some - if not all - uses of this should migrate to the new extension and fall back to a default from a ChangeBuilder).
Change-Id: Ie2e6eaba78c96a1cbd79eba881e12bbeef724aa8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/443122
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@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>
Modifies `GeneratedDirectory.outputDirPath` and
`GeneratedFile.outputPath` to be relative to the SDK's `pkg` directory
rather than relative to the containing package. Accordingly, modifies
the `GeneratedContent` methods `check`, `checkAll`, `generate`,
`generateAll`, `output`, as well as the `DirectoryContentsComputer`
and `FileContentsComputer` callbacks, so that their first parameter is
the path to the `pkg` directory rather than the path to the containing
package.
Also modifies the `readApi` functions in `pkg/analysis_server` and
`pkg/analyzer_plugin` to accept a path to the `pkg` directory rather
than a path to the containing package, since these functions are
called by code generation callbacks.
These changes should make code generation logic easier to reason
about. They also will make it easier to move the outputs of code
generation from one package to another, which will pave the way for
some follow-up work in which I intend to start sharing error message
representations belonging to `pkg/analyzer`, `pkg/front_end`, and
`pkg/_fe_analyzer_shared`.
Change-Id: Ia9b369b16f2df931c8a472f91400f2c5a0b8be9d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/438480
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change removes the top level variable `allTargets` from
`pkg/analyzer_utilities/lib/tool/api.dart` and replaces it with a
method `allTargetsForPackage`, parameterized by the name of the
package for which an `api.txt` file is generated. The individual code
generators that make use of this function now all have their own top
level variable `allTargets`.
In addition to being conceptually clearer (since we no longer have a
single `allTargets` variable with different meanings depending on
where it's used), this paves the way for a CL I am working on that
will change the `GeneratedContent` based code generators so that they
use paths relative to the `pkg` directory. That in turn should make it
simpler to move some of the code generated files that have to do with
error messages from `pkg/analyzer` to `pkg/_fe_analyzer_shared`.
Change-Id: Id636ddbca27c46ae4242bbf8e4b6f7b8dae4d4e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/438481
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This change adds a `@Deprecated` annotation to each of the analyzer's
generated error code files, with a deprecation message that says the
corresponding non-code-generated file should be imported instead. For
example, `package:analyzer/src/error/codes.g.dart` now has a
deprecation message saying that
`package:analyzer/src/error/codes.dart` should be used instead.
All existing imports of these libraries are switched to the
corresponding non-code-generated file, where possible. (The only
circumstance in which it's not possible is when the corresponding
non-code-generated file imports the code-generated file---e.g., when
`package:analyzer/src/error/codes.dart` imports
`package:analyzer/src/error/codes.g.dart`. In these cases, the
deprecation warning is suppressed with an "ignore" comment.)
This change is part of a long term effort to unify the analyzer and
CFE representations of error messages. It paves the way for a
follow-up CL in which I intend to move some of the generated code from
`package:analyzer` to `package:_fe_analyzer_shared`, to allow it to be
shared with the CFE.
Change-Id: Ie91dc8fc9357defa8974cbe6836d582979d87d81
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437840
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Before an assist call on a file with non-windows lineendings would first
search through the entire file for Windows line endings, then search for
the non-Windows line endings. As such Windows line endings was faster.
This CL changes the semantics slightly from "Windows line endings if
any Windows line endings exist" to "whatever line endings are first
used" which should be good.
It speeds up assist calls with non-Windows line endings:
Statistics on 5 runs each:
```
Windows / 2000: No change.
Windows / 4000: No change.
Windows / 8000: No change.
Unix / 2000: 1000 assist calls: -46.9900% +/- 6.1715% (-0.88 +/- 0.12) (1.86 -> 0.99)
Unix / 4000: 1000 assist calls: -59.1561% +/- 6.3982% (-1.79 +/- 0.19) (3.03 -> 1.24)
Unix / 8000: 1000 assist calls: -63.8429% +/- 4.3083% (-3.68 +/- 0.25)(5.76 -> 2.08)
```
Change-Id: I61278ed4ad31b891e87951da0a6162fe37376888
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437224
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The diff makes this change look bigger than it is.
Here's how the code worked before: `compute()` called `_addFromProducers()`. `_addFromProducers()` had a local function, also
called `compute()`, which is called per CorrectionProducer. The local
`compute()` function would unconditionally create a ChangeBuilder and
call each CorrectionProducer's `compute()` method, then call back out
to an instance method called `_addFixFromBuilder()`, which would drop
the computed change on the floor if `fixKind` was `null`.
This CL contains the following changes to the above system:
* The local `compute()` function and the instance method,
`_addFixFromBuilder()` are combined together, into one instance
method, `_addFromProducer()`.
* Then, the `fixKind` check is moved to the very top of that
method, bailing out _before_ computing changes if `fixKind == null`.
Change-Id: I6c61059fc36ec1587b15ca01b43830a5b179da9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417326
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Work towards #60635
In this change, we rework the AnalysisErrorListener deprecation to
better support users who have their own class that implements
AnalysisErrorListener. This change introduces a sealed supertype,
DiagnosticOrErrorListener, with the old implementation,
AnalysisErrorListener, and the new implementation, DiagnosticListener,
as its sole direct subclasses. Users who have implemented
AnalysisErrorListener should be able to instead implement
DiagnosticListener, and their class is an acceptable instance of
DiagnosticOrErrorListener, wherever that is needed.
In a breaking change we can drop AnalysisErrorListener and deprecate
DiagnosticOrErrorListener, and in the next breaking change, we can drop
DiagnosticOrErrorListener.
For reference, see the first API difference when deprecating AnalysisErrorListener and introducing DiagnosticListener: https://github.com/dart-lang/sdk/commit/903d77cc8229972a424941dcb7b7b79741e833eb#diff-dec15868961d7eadcd009f49d129bebcdb747aaa8dbfde5f5a08884e0cf11e32
Change-Id: I3ccf11d54b41fbca98d020d89978d250c16b4c04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436480
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Work towards https://github.com/dart-lang/sdk/issues/60635
I tried to keep this minimal but still sensible:
* Rename AnalysisErrorListener and all subtypes to use 'Diagnostic'.
* Rename all instantiations of such classes if they previously
contained the word 'error'.
* Rename `RecordingDiagnosticListener.errors` to `.diagnostics`.
* Rename some _testing_ instance members that had the word 'error'
to instead use 'diagnostic'.
Change-Id: I3948e27ba28ac2494092e04f4e1d201a20cc1135
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433004
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is a big CL; no code is really "changed." We basically move 3
components into the public API, which can all be reviewed concisely
in the `api.txt` file.
* The AnalysisRule classes: `AbstractAnalysisRule` (which is good to
make public as a lot of the public API is specified and documented
here), `AnalysisRule`, `MultiAnalysisRule`.
* The Pubspec classes, available for linting pubspec files:
`PubspecDependency`, `PubspecDependencyList`, `PubspecEntry`,
`PubspecEnvironment`, `PubspecGitRepo`, `PubspecHost`, `PubspecNode`,
`PubspecNodeList`, `PubspecVisitor`.
* The `RuleVisitorRegistry` class. This class is needed by analysis
rule authors, and is part of the public API of AnalysisRule.
Change-Id: Ib1803180de9469f4ff39cf1778f96787f5f74b14
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432363
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
For the analyzer plugin APIs, these classes should not have the word
'Lint' in them, as they are used for all analysis rules, whether they
report lints or warnings.
* LinterContext -> RuleContext
* LinterContextWithParsedResults -> RuleContextWithParsedResults
* LinterContextWithResolvedResults -> RuleContextWithResolvedResults
* LintRuleUnitContext -> RuleUnitContext
I'm open to better names for these. Some of these suffer from a
chain-of-nouns name (a "RuleUnitContext" is a Context for a Unit for
a Rule). So we could go with "UnitContextForRule" and "ContextForRule"
or other ideas like that.
Only RuleContext and RuleUnitContext will be public API.
Change-Id: I5550736beaba7e39b36e7b5584ca6d023aa4d02b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431703
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Sam Rawlins