| commit | df707ac85e9a81b73c80638b759aede6be80ebbb | [log] [tgz] |
|---|---|---|
| author | Sam Rawlins <srawlins@google.com> | Fri Apr 05 00:17:58 2024 +0000 |
| committer | Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Apr 05 00:17:58 2024 +0000 |
| tree | 3aa8307d71503e82bc4ae7d56712c6272c8848c3 | |
| parent | 01c4d15a959d0eda29d9186f4957be65f343cd55 [diff] |
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>
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 is free and open source.
See LICENSE and PATENT_GRANT.
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).
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.
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.