DAS: Refactor the logic determining the location of a new ignore-comment

I renamed a few classes, then sorted them, so the diff is big.

Broadly, here is a summary of the code before: two "ignore diagnostic"
correction producers were in place, and the one that inserts a
"ignore_for_file" comment (IgnoreDiagnosticInFile) uses a
`CorrectionUtils.getInsertionLocationIgnoreForFile` function to get an
InsertionLocation object, then passes that to `_computeEdit()`, a
method defined in a parent class. `_computeEdit()` takes that
InsertionLocation object, and uses LineInfo, to determine whether we
need to _append_ to an existing ignore-comment (in which case all
other InsertionLocation information is discarded), or write a full
comment, and use the InsertionLocation prefix and suffix.

To me this was a pretty complicated set-up: IgnoreDiagnosticInFile
calls out to a function defined in a separate library to do "the first
half" of the location calculation. Then the `_computeEdit()` function
has to finish the job, which might involve ignoring computations done
in the first half.

I've changed it to instead be the following design: Each class,
IgnoreDiagnosticInFile and IgnoreDiagnosticOnLine, wholly implements
`compute()` (removing the parent `_computeEdit()` method). The former
class has the much bigger task of finding an appropriate position near
the top of the file in which it can insert a comment. Instead of
tracking a lot of variables along the way, this code quickly calls out
to `insertAt()` as soon as it knows where it is inserting, whether it is
appending, and whether we need a newline before the comment, or after.
So everything about the offset, possible prefix, suffix, and decision
to-append is done in one place. The latter class,
IgnoreDiagnosticOnLine, has a much simpler `compute()`, the most
complex part is determining whether to append to an existing comment.
There is not much duplicated. The `insertAt()` method is defined in
the parent class; it is nice to have a method that is agnostic to the
ignore comment being inserted; it just calculates an indent, and
writes the comment.

Summary of changes:

* AbstractIgnoreDiagnostic, the parent of the two mentioned classes,
  and IgnoreDiagnosticInAnalysisOptionsFile, is actually a base class,
  shouldn't be public, and it's `_computeEdit()` was not relevant for
  the 3rd subclass. So I rename it to _BaseIgnoreDiagnostic, and add a
  new small class in between: _DartIgnoreDiagnostic. The new class
  defines `insertAt()` (only relevant for Dart files), and requires
  that subclasses define their `ignorePrefix`.
* `_isCodeUnignorable` is changed from a method to a getter.
* `DartEditBuilderImpl._linePrefix` is moved to an extension on ResolvedUnitResult, along with some helpers. It is moved to `src/` so
  not technically part of public API. It should be moved to
  server_plugin soon.
* `getInsertionLocationIgnoreForFile` and `getLinePrefix` are removed.

Change-Id: I4757ea2d8a3b43eeec0c8895c5c1fb3edc3ca8a3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361006
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
6 files changed
tree: 3aa8307d71503e82bc4ae7d56712c6272c8848c3
  1. .dart_tool/
  2. .github/
  3. benchmarks/
  4. build/
  5. docs/
  6. pkg/
  7. runtime/
  8. samples/
  9. sdk/
  10. tests/
  11. third_party/
  12. tools/
  13. utils/
  14. .clang-format
  15. .gitattributes
  16. .gitconfig
  17. .gitignore
  18. .gn
  19. .mailmap
  20. .style.yapf
  21. AUTHORS
  22. BUILD.gn
  23. CHANGELOG.md
  24. codereview.settings
  25. CONTRIBUTING.md
  26. DEPS
  27. LICENSE
  28. OWNERS
  29. PATENT_GRANT
  30. PRESUBMIT.py
  31. README.dart-sdk
  32. README.md
  33. sdk.code-workspace
  34. sdk_args.gni
  35. sdk_packages.yaml
  36. SECURITY.md
  37. WATCHLISTS
README.md

Dart

An approachable, portable, and productive language for high-quality apps on any platform

Dart is:

  • Approachable: Develop with a strongly typed programming language that is consistent, concise, and offers modern language features like null safety and patterns.

  • Portable: Compile to ARM, x64, or RISC-V machine code for mobile, desktop, and backend. Compile to JavaScript or WebAssembly for the web.

  • Productive: Make changes iteratively: use hot reload to see the result instantly in your running app. Diagnose app issues using DevTools.

Dart's flexible compiler technology lets you run Dart code in different ways, depending on your target platform and goals:

  • Dart Native: For programs targeting devices (mobile, desktop, server, and more), Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an AOT (ahead-of-time) compiler for producing machine code.

  • Dart Web: For programs targeting the web, Dart Web includes both a development time compiler (dartdevc) and a production time compiler (dart2js).

Dart platforms illustration

License & patents

Dart is free and open source.

See LICENSE and PATENT_GRANT.

Using Dart

Visit dart.dev to learn more about the language, tools, and to find codelabs.

Browse pub.dev for more packages and libraries contributed by the community and the Dart team.

Our API reference documentation is published at api.dart.dev, based on the stable release. (We also publish docs from our beta and dev channels, as well as from the primary development branch).

Building Dart

If you want to build Dart yourself, here is a guide to getting the source, preparing your machine to build the SDK, and building.

There are more documents on our wiki.

Contributing to Dart

The easiest way to contribute to Dart is to file issues.

You can also contribute patches, as described in Contributing.