[Komoszek]

ciach skipped operators unless --also operators was set, and then it reported every operator that only other libraries used. The reference search misses those uses: it finds a + b only in the library that declares +, it finds no relational pattern such as case < 0, and for == it lists every use of Object.== in the SDK. This pull request finds the uses of operators through the analysis server, reports unused operators by default and removes --also operators. It builds on the renaming that #151 added for call methods.

How it works

• Hierarchy. For each operator, operator_hierarchies.dart collects the operators that it overrides and that override it, through every supertype and subtype of its class. An operator that a subtype inherits along with it joins too: abstract class Both implements Left, Right {} joins Left.+ and Right.+. When one of them is outside the analysis root, such as Object.== or ListBase.[], the operator is never reported: its uses can't be found, and the SDK calls == from Set and Map.
• Rename. In unsaved copies of the files, the operator keyword of every member becomes o$$$$$$$ and the name becomes spaces, so no position moves. Every new error is a use, and it counts for every member of the hierarchy, as the reference search counts a call through a subclass.
• Rounds. Each hierarchy is renamed in a round of its own: after a + b fails, (a + b) * 2 has no error at *.
• The call and operator lookups each restore the files that they changed, through withUnsavedChanges. While they change files, the open files are closed, because the server analyzes a change about three times faster then.

LspClient.didChange now opens a document that isn't open, and waitForChangesAnalyzed waits through a hover request, which the server can answer only after it resolves the changed file. The foldingRange request that it used before could be answered before the new errors were published.

--also operators and also: [operators] are errors that say to drop the value, and --no-operators says to use // ciach:ignore. MIGRATION.md covers the change, including FinderOptions.skipOperators for library users.

Cost

Each round costs one analysis of the libraries that import the renamed files:

• xml 7.1.0: 13-19 s before, 18 s after, with 10 fewer findings, all of them used operators such as XPathDuration.+ and XmlCache.[]. Without closing the files, it took 32 s.
• fixnum 1.1.1: 0.7 s before, 3 s after, with 6 fewer findings, such as IntX.%.

Limits

• A use through dynamic gives no error, as for every member.
• A use of + through B also counts for C.+ when C is a sibling of B, although the use can't call it. So with --also overrides, C.+ isn't reported, even when nothing calls it.

Tests

test/finder/operators_test.dart scans example/lib/scenarios/operators*.dart, which cover every operator, compound assignments, relational patterns, extensions, enums, mixins, extension types, overrides through one and two supertypes, and an override in a file that isn't scanned. Small packages written by the tests cover a three-level override chain, an SDK operator that a class overrides through an abstract class that doesn't declare it, a class that inherits + from two interfaces, and an operator whose name follows operator on the next line. Without renaming the whole hierarchy, the first test also reports Round.-, which code uses only through its subclass. Without the walk through all supertypes, the SDK operator test reports Leaf.[] and Leaf.[]=. Without joining the operators that a subtype inherits, the two-interface test reports Left.+ and Right.+, which code uses through Both. test/lsp/lsp_client_test.dart checks that closeAll closes every open document.

With Dart 3.13.5, dart analyze --fatal-infos, dart format and all tests pass. In website/, images/og.png fails on this machine, as noted in #151.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RWsUwSKJvdgiVh4gAHboH5

[Komoszek]

Are operatora talent into account in --no-public and exported-packages?

[Komoszek]

Now semantin tokens are always fetched. Is it intentional?

[Komoszek]

Yes. The call is unconditional now, but it fetches tokens only for the files of the uses that the two lookups found, and it skips each file whose tokens are already cached. When a lookup fails, it adds no uses, and when neither finds any, semanticTokensFor returns before it sends a request. That is what main did for the call uses: it skipped the call only when the lookup failed, and then there were no uses to fetch tokens for. The tokens are still needed, because the verdict reads the comments and annotations around each use, as it does for the references that references returns.

---

Generated by Claude Code

[Komoszek]

Why was it changed?

[Komoszek]

Because foldingRange didn't make the wait reliable. The server answers foldingRange from the parsed file alone, so the answer could arrive before the server reported that it had started analyzing the change. The wait then ended at once, and a round read the errors from before the rename. During this pull request, the operator tests reported used operators in some runs because of it. The server can answer hover only after it resolves the changed file, and it reports isAnalyzing: true before it starts. So once the hover answer arrives, waiting until the server is idle covers the whole analysis.

---

Generated by Claude Code

[Komoszek]

What does it mean?

[Komoszek]

show gives the server new content for some files, and it puts back the content on disk of every file that it changed before and that this call leaves out. For example, round 1 calls show({a: renamedA}), and round 2 calls show({b: renamedB}). Round 2 then sends renamedB for b and the content on disk for a, so only b's operator stays renamed. show(const {}) restores everything.

ae58b34 rewrites the doc comment to say this: "Sends [texts], the new content of files by path, to the server. A file that an earlier call changed and [texts] leaves out gets its content on disk back."

---

Generated by Claude Code

[Komoszek]

I don't understand. Is the method name correct? Is the comment understandable?

[Komoszek]

Neither was good: _outsideNames said where the errors aren't, not what the method returns. It drops the errors at a declaration's name, because those come from the declaration itself, such as a class that no longer implements its interface after its operator is renamed, and they aren't uses.

Done in 9c81cb3: the method is now _rangesOfUses, documented as "Returns the ranges of [errors] in [path] that mark uses. An error at a declaration's name isn't a use: it comes from the declaration itself, such as a class that no longer implements its interface." The doc of newErrors now says only that it returns the ranges of the new errors that mark uses.

---

Generated by Claude Code

[Komoszek]

Look at other methods and comments and recheck them

[Komoszek]

Done in 2eeac44. I reread every name and comment that this pull request adds, and renamed those that didn't say what they do:

• unsaved_changes.dart: show → send, newErrors → usesByPath, _errors → _publishedErrors, _changed → _changedPaths, _change → _send.
• operator_hierarchies.dart: _overriddenOf → _overriddenBy (the operators that a member overrides), _overriddenIn → _operatorsInSupertypes, _operatorIn → _declaredOperator, _isInside → _isInsideAnalysisRoot, and OperatorHierarchy.operators → candidates, because it holds the candidates among the members. The parameters of type _OperatorKind are now all named kind.
• operator_uses.dart: _newName → _renamedKeyword, _renamed → _renamedContent.
• semantic_tokens.dart: lastCodeBefore → lastNonCommentBefore.

Their doc comments now match the new names. For example, OperatorHierarchy is "One override hierarchy: operators that override each other", and _publishedErrors says that warnings and hints are left out because a use of a renamed declaration is always an error. All tests pass.

---

Generated by Claude Code

[Komoszek]

This name doesn't actually reflect what it does. It makes sense obył when news error === use from the perspective of the caller. Please give 5 proposals how we could improve that

[Komoszek]

Agreed: the method returns the ranges of the errors that the changes added, without those at a declaration's name, and only the callers read them as uses. Five options, each paired with a name for the private helper, which has the same problem:

1. newErrorRanges(), with the helper _rangesNotAtDeclarationNames(path, errors). The doc says that errors at declaration names are left out, and the callers keep the name usesByPath for their variable.
2. addedErrorRanges(), with the same helper. "Added" says that the errors are compared with those before the changes.
3. newErrorRangesByPath(), with the same helper, if the key of the map should show in the name.
4. newErrorsOutsideDeclarations(), with the helper _outsideDeclarationNames(path, errors). This names the filter, but it is long, and it says where the errors aren't rather than what is returned.
5. Split it: newErrors() returns the new Diagnostics by path, and a separate withoutDeclarationNames(errors) in each caller drops those at declaration names. The names are exact, but both callers repeat the filter call.

I'd take 1: it says what comes back, and the filter is a detail of the doc comment, as the left-out warnings are in _publishedErrors. Which one should I use?

---

Generated by Claude Code

[Komoszek]

sure, shouldn't this helper _rangesNotAtDeclarationNames be reused for both implicit calls and operators? Those things are pretty similar

[Komoszek]

Done in f2b8995: the method is now newErrorRanges(), and its helper is _rangesNotAtDeclarationNames.

It is already shared: both findImplicitCalls and findOperatorUses call changes.newErrorRanges(), and that is the only caller of the helper. On main, implicit_calls.dart had its own copy of this filter, _usesAmong. This pull request moved it into UnsavedChanges, so that both lookups use one copy.

---

Generated by Claude Code