How a file change is propagated to other dependent files?

[Dmitry Zhifarsky]

Hi, I'm trying to find a place where the file's unit is recalculated when another file it depends on is changed.
Could you point me out to that place?

[Konstantin Shcheglov]

  It depends on the level you want to know this.

  For `ServerPlugin` you call `contentChanged`, and then it uses analyzer to decide which files were affected, and invokes `handleAffectedFiles()`, which eventually invokes `analyzeFile()`. The implementation of `analyzeFile()` will usually invoke `AnalysisSession.getResolvedUnit()` and do checks.

  For the analyzer itself, you call `AnalysisDriver.changeFile()`, which accumulates these changes, and then in `_applyPendingFileChanges()` applies all accumulated changes. It uses a `_removePotentiallyAffectedLibraries()` that collects any files that depend on a changed file, directly or indirectly. These files are potentially affected, so we will try to recompute elements for them, and re-analyze them.

On Wed, Feb 15, 2023 at 3:00 AM Dmitry Zhifarsky <dimann...@gmail.com> wrote:

Hi, I'm trying to find a place where the file's unit is recalculated when another file it depends on is changed.
Could you point me out to that place?

--
You received this message because you are subscribed to the Google Groups "Dart Analyzer Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to analyzer-discu...@dartlang.org.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/analyzer-discuss/d15d3598-6e81-4b9b-bf6a-71e54e51f928n%40dartlang.org.

--

Konstantin Scheglov

Software Engineer

Google, Inc.

[Dmitry Zhifarsky]

Thank you, the second one is what I've been looking for.

Finally have time to look deeper into the analyzer implementation (the linking, scope resolution and flow analysis look so interesting 😁).
If I'm not mistaken, the resolved unit always goes through linting / analysis errors calculation. Any chance this work can be skipped with a flag?
Also, talking about the affected files: for barrel files, for example, will the analyze invalidate all the files that import a barrel file or it tracks exact usages and invalidates partially?

среда, 15 февраля 2023 г. в 22:29:05 UTC+4, sche...@google.com:

[Konstantin Shcheglov]

On Wed, Feb 15, 2023 at 10:53 AM Dmitry Zhifarsky <dimann...@gmail.com> wrote:

Thank you, the second one is what I've been looking for.

Finally have time to look deeper into the analyzer implementation (the linking, scope resolution and flow analysis look so interesting 😁).
If I'm not mistaken, the resolved unit always goes through linting / analysis errors calculation. Any chance this work can be skipped with a flag?

  Well, we don't have such an implementation for doing only partial resolution, without computing diagnostics.

  The closest is `_resolveForCompletion()` that tries to do partial resolution, and no diagnostics.

  We need to be careful and not to put partial results into any caches (for priority files, or serialized into the byte store).

 

Also, talking about the affected files: for barrel files, for example, will the analyze invalidate all the files that import a barrel file or it tracks exact usages and invalidates partially?

  Invalidation is conservative, meaning that yes, if anything changed in the API of any exported library, the whole exporting library will be relinked. And any files that import this barrel library will be fully re-resolved.

 

среда, 15 февраля 2023 г. в 22:29:05 UTC+4, sche...@google.com:

  It depends on the level you want to know this.

  For `ServerPlugin` you call `contentChanged`, and then it uses analyzer to decide which files were affected, and invokes `handleAffectedFiles()`, which eventually invokes `analyzeFile()`. The implementation of `analyzeFile()` will usually invoke `AnalysisSession.getResolvedUnit()` and do checks.

  For the analyzer itself, you call `AnalysisDriver.changeFile()`, which accumulates these changes, and then in `_applyPendingFileChanges()` applies all accumulated changes. It uses a `_removePotentiallyAffectedLibraries()` that collects any files that depend on a changed file, directly or indirectly. These files are potentially affected, so we will try to recompute elements for them, and re-analyze them.

On Wed, Feb 15, 2023 at 3:00 AM Dmitry Zhifarsky <dimann...@gmail.com> wrote:

Hi, I'm trying to find a place where the file's unit is recalculated when another file it depends on is changed.
Could you point me out to that place?

--
You received this message because you are subscribed to the Google Groups "Dart Analyzer Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to analyzer-discu...@dartlang.org.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/analyzer-discuss/d15d3598-6e81-4b9b-bf6a-71e54e51f928n%40dartlang.org.

--

Konstantin Scheglov

Software Engineer

Google, Inc.

[Dmitry Zhifarsky]

Thank you, I'll take a look at the `_resolveForCompletion`.

> Invalidation is conservative, meaning that yes, if anything changed in the API of any exported library, the whole exporting library will be relinked.

Was this approach intentionally chosen over a more atomic one or there are hidden costs that make the atomic one too bad?

среда, 15 февраля 2023 г. в 22:59:23 UTC+4, sche...@google.com:

[Konstantin Shcheglov]

On Sat, Feb 18, 2023 at 12:00 AM Dmitry Zhifarsky <dimann...@gmail.com> wrote:

Thank you, I'll take a look at the `_resolveForCompletion`.

> Invalidation is conservative, meaning that yes, if anything changed in the API of any exported library, the whole exporting library will be relinked.

Was this approach intentionally chosen over a more atomic one or there are hidden costs that make the atomic one too bad?

  More atomic invalidation is hard and error-prone.

  Depending on the granularity, the cost of tracking dependencies might become too high.