Renaming a local variable does not update references in a workspace with overlapped analysis roots, depending on the paths

Describe the bug
Rename only applied to first parameter declaration, when analysis server works in a specific configuration.

This bug is only seems to occur when sub package is VS Code WS folder and root folder is also VS Code WS folder and there is analysis_options.yaml file in sub package.

Removing analysis_options.yaml or root folder from VS Code workspace mitigates the issue.

To Reproduce

Create pub workspace in project folder
Create submodule in a subfolder
Add subfolder and project folders as VS Code workspace folders
Create analays_options.yaml in submodule
Try to rename a symbol

Attaching example environment.
Open test.code-workspace and try to rename variable a in main.dart.
dart_code_test.zip

Expected behavior
Should work as normal.

Screenshots

Please complete the following information:

You can run the Dart: Collect Diagnostic Information command from the VS Code command palette (F1) to easily capture this information or provide it manually.

Operating System and version: Microsoft Windows [Version 10.0.19045.5854]
VS Code version: 1.101.0 dfaf44141ea9deb3b4096f7cd6d24e00c147a4b1 x64
Dart extension version: v3.113.20250611
Dart/Flutter SDK version:
Flutter 3.32.3 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 5c1433509f (3 days ago) • 2025-06-11 13:12:24 -0700
Engine • revision 31c4875c7a (9 days ago) • 2025-06-05 08:39:10 -0700
Tools • Dart 3.8.1 • DevTools 2.45.1

Analysis server log:
Dart-Code-Log-2025-05-00 04-03-44.txt

@Zekfad

@Zekfad Does this consistently reproduce for you? I'm testing with your project and the same version of Flutter, but it's not happening:

5548.mp4

I did come across a very similar issue with some analysis server tests recently and it was caused by the ASTs not being cached for the offending file, but ASTs for open files should always be cached (and it seems clear from the screenshots that the file is open!).

If you can still reproduce, can you confirm how you are opening the file - for example is it automatically opened by VS Code when you opened the project, or did you open it manually? Is it open as a "preview" (with an italic name in the tab)?

@DanTup

@DanTup it's constantly reproducible, I've originally found it in our project and then dissected into a smaller setup from the scratch. File is opened manually, issue happens in previews as well.
Maybe I need to record additional logs if there are any to?

Using your example project, Could you try opening your VS Code Workspace settings file (with the Preferences: Open Workspace Settings (JSON) command) and add:

"dart.analyzerLogFile": "logs/analyzer.txt",

Then restart VS Code and reproduce the issue, then grab a copy of that file and attach here? It will be similar to your previous log, but will include the full analysis server communication from opening VS Code which should include things like opening the file. I might be able to reproduce by replaying that log.

Thanks!

@DanTup

Here's the log, @DanTup

analyzer.txt

@Zekfad

@Zekfad thanks! Unfortunately it wasn't very revealing. It clearly shows the broken behaviour you're seeing, but there are no obvious differences to my log.

Could you try closing the file with the test code, then reloading VS Code (with the logging still enabled), then wait a few seconds (for the analysis server to finish starting up) after loading the project before you open main.dart, and then try the rename again, and if it fails again, attach the updated log. This will eliminate the timing of the textDocument/didOpen request as a factor.

Thanks!

Here's started from 0 tabs, waited a few secs and then opened file and renamed.

analyzer.txt

I think I have some new clue! I've tried to copy folder to the same drive as flutter sdk installed and it started to work.
Try to open sample WS from a different drive than flutter sdk installation.
Also I have custom pub cache: PUB_CACHE=D:\Cache\Pub in my environment, and installation is FLUTTER_ROOT=D:\Android\flutter

I think I have some new clue! I've tried to copy folder to the same drive as flutter sdk installed and it started to work.

Hmm, interesting. I tried this (by putting the project on drive C, whereas everything else is on D), but still no repro. Is there anything special about your drive Z? Is it just another partition of a standard drive, or something like a network/USB drive (or created with SUBST)?

It's a separate drive with a single partition, D where sdk is a second partition of system drive. Also my Desktop is configured to be on drive Z and I've tested WS from my desktop and original issue came from a subfolder on desktop.

I currently went away from my computer, but I could do additional testing like starting from USB stick when I'll return.

I set up a drive Z: and put the project there but still no joy. I also tried moving my Flutter SDK to drive C: and leaving the project on D:. but also no repro. I suspect there's something more than just the drive letter.

We've had some issues in the past caused by drive letter casing differences, however we generally normalize them always to uppercase to try to avoid these issues now. Let me know if you figure out anything else that might help, and I'll try some more things and compare our logs better.

While comparing logs, I noticed the long lines in yours are truncated. Is it possible you can add the following to your workspace settings and recapture the last log file?

"dart.maxLogLineLength": 99999999,

This will avoid long lines being truncated. Thanks!

Sure, in about few hours i should be able to get back to it and reupload full log.

Another thing to try when next reproducing... Run the Dart: Open Analyzer Diagnostics command from the command palette, then click the Contexts tab on the left, and get a screenshot of the of Priority Files:

I wonder why different paths consistently affect this though.

The drivers are stored in a Map<Folder, AnalysisDriver> and Folder uses path.hashCode as its hash code. This means the order of whether the nested or parent folder is first when iterating the map of drivers will depend on the paths (or more specifically, their hash codes).

So the ones you found that trigger this likely have hash codes in a different order to those that don't.

So the ones you found that trigger this likely have hash codes in a different order to those that don't.

What a chance huh, since it was originally in another project and I created repro sample, which triggered the issue from the first try.

@bwilkerson

@bwilkerson I believe I understand this issue now, but I'm not certain at which point the bug is so I'd like your input. I'll summarize the issue to avoid you reading all of the above.

The bug is that for "some workspaces" renaming local variables do not rename the uses of those variables. We actually discussed something like this similar that was caused by the element model not being cached because the file was not priority - this is not the same (although it is caused by duplicate/mismatched elements, and the search engine fetching another resolved AST - see dart-lang/sdk#60735).

It reproduces under the following conditions:

There are overlapped analysis roots in the workspace (and therefore multiple AnalysisDrivers for which the target file is within their root)
The hashCodes of the paths of the overlapped analysis roots must be such that iterating driverMap provides the outer-most driver first

Usually when we get the AnalysisDriver for a file, we sort so that we always get the nearest one:

https://github.com/dart-lang/sdk/blob/a48f47f5446db70fdfdd0ddd053c3dbc8fed7eea/pkg/analysis_server/lib/src/analysis_server.dart#L637

This is what happens for the rename handler. We get the "correct" driver and find the Element for the local variable.

However in the search engine when we search for references, we assign each file to a driver (_createSearchedFiles) by enumerating the drivers (in driverMap - which is why the hashCode of the path affects the results) and tell them to claim the files they analyze with ownAnalyzed. So if the outer-most driver was first in the list, it claims the target file, and then the search is done using that driver (instead of the inner-most one):

https://github.com/dart-lang/sdk/blob/a48f47f5446db70fdfdd0ddd053c3dbc8fed7eea/pkg/analysis_server/lib/src/services/search/search_engine_internal.dart#L163

I feel like _createSearchedFiles and/or ownAnalyzed should perhaps be smarter here to not claim files that would be contained by inner drivers. However, I'm wondering whether the nested files should be in driver.addedFiles for the outer context at all (it is addedFiles that is used by ownAnalyzed). So I'm wondering if the issue is further up?

If I review the diagnostics page, I see the open file listed in "Added Files" for both of the contexts:

@scheglov

I feel like _createSearchedFiles and/or ownAnalyzed should perhaps be smarter here to not claim files that would be contained by inner drivers. However, I'm wondering whether the nested files should be in driver.addedFiles for the outer context at all (it is addedFiles that is used by ownAnalyzed). So I'm wondering if the issue is further up?

It's my understanding that addedFiles should not include files in a directory that is owned by a different analysis context. So I think you're right and that the problem was introduced somewhere earlier in the process.

@scheglov

Theoretically we should invoke AnalysisDriver.addFile(path) only for files that are not inside another ContextRoot.
If there is a bug, it might be in analyzedFiles().

  void _addAnalyzedFilesToDrivers() {
    for (var analysisContext in _analysisContextCollection!.contexts) {
      for (var path in analysisContext.contextRoot.analyzedFiles()) {
        if (file_paths.isDart(resourceProvider.pathContext, path)) {
          analysisContext.driver.addFile(path);
        }
      }
    }
  }

Thanks! I've added some additional notes on the CL (https://dart-review.googlesource.com/c/sdk/+/435161) for your input.

[analyzer] Exclude nested analysis roots from their parents contexts

This was fixed by dart-lang/sdk@2285b68. The change is in the SDK so will ship in a future Dart/Flutter SDK.

Navigation Menu

Repository navigation

Renaming a local variable does not update references in a workspace with overlapped analysis roots, depending on the paths #5548

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Renaming a local variable does not update references in a workspace with overlapped analysis roots, depending on the paths #5548

Description

Activity

DanTup commented on Jun 16, 2025

Zekfad commented on Jun 16, 2025

DanTup commented on Jun 16, 2025

Zekfad commented on Jun 16, 2025

DanTup commented on Jun 16, 2025

Zekfad commented on Jun 16, 2025

Zekfad commented on Jun 16, 2025

DanTup commented on Jun 16, 2025

Zekfad commented on Jun 16, 2025

DanTup commented on Jun 16, 2025

DanTup commented on Jun 16, 2025

Zekfad commented on Jun 16, 2025

DanTup commented on Jun 16, 2025

6 remaining items

DanTup commented on Jun 17, 2025

Zekfad commented on Jun 17, 2025

DanTup commented on Jun 17, 2025

bwilkerson commented on Jun 17, 2025

scheglov commented on Jun 17, 2025

DanTup commented on Jun 18, 2025

DanTup commented on Jun 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions