[analyzer] Flutter project with packages inside breaks textDocument/definition and other navigation

[tupos]

dart --version
Dart SDK version: 2.19.1 (stable) (Tue Jan 31 12:25:35 2023 +0000) on "windows_x64"

flutter --version
Flutter 3.7.1 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 7048ed95a5 (3 days ago) • 2023-02-01 09:07:31 -0800
Engine • revision 800594f1f4
Tools • Dart 2.19.1 • DevTools 2.20.1

Editor is VSCode with Dart and Flutter extensions 3.58.0

To reproduce the issue

flutter create test
cd test

Open lib/main.dart and inside MyApp::build add prior to return

@override
  Widget build(BuildContext context) {
    var w = TextFormField();
...

Jump to definition TextFormField(). Inside constructor definition it is possible to jump to definition of any type.

Now being in test folder create package

dart create -t package test_package

Restart dart analysis server by F1 -> Dart: Restart Analysis Server. The jump to definition is completely broken for many types like

TextFormField({
    super.key,
    this.controller,
    String? initialValue,
    FocusNode? focusNode,  // broken
    InputDecoration? decoration = const InputDecoration(),
    TextInputType? keyboardType, // broken
    TextCapitalization textCapitalization = TextCapitalization.none, // broken
    TextInputAction? textInputAction, // broken
    TextStyle? style,  // broken
    ...

If now the test_package is removed from the test project and language server is restarted the navigation is working again.
Inside the logs I can only see

[11:48:16 PM] [Analyzer] [Info] ==> Content-Length: 253
[11:48:16 PM] [Analyzer] [Info] ==> {"jsonrpc":"2.0","id":15,"method":"textDocument/definition","params":{"textDocument":{"uri":"file:///.../flutter/packages/flutter/lib/src/material/text_form_field.dart"},"position":{"line":101,"character":6}},"clientRequestTime":1675550896958}
[11:48:16 PM] [Analyzer] [Info] <== Content-Length: 37
Content-Type: application/vscode-jsonrpc; charset=utf-8
[11:48:16 PM] [Analyzer] [Info] <== {"id":15,"jsonrpc":"2.0","result":[]}

and

1675550896958:Req:{"jsonrpc"::"2.0","id"::15,"method"::"textDocument/definition","params"::{"textDocument"::{"uri"::"file::///.../flutter/packages/flutter/lib/src/material/text_form_field.dart"},"position"::{"line"::101,"character"::6}},"clientRequestTime"::1675550896958}
1675550896959:Res:{"id"::15,"jsonrpc"::"2.0","result"::[]}

[devoncarew]

@DanTup - do you mind doing some investigation here to run down where the problem might be?

[DanTup]

@tupos I'm having trouble reproducing this. I'm on stable Flutter 3.7.1 and followed your steps. I still have the Flutter project open and the source for the TextFormField constructor open, but navigating to types like TextInputType work fine:

Are you able to provide the complete log file from when the server starts to when this occurs? You can enable writing the log to disk by adding the following to your Workspace settings (F1 -> Preferences: Open Workspace Settings (JSON)):

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

Thanks!

[tupos]

@DanTup From your screenshot I see that you use mac os.
I just tried it on mac os and indeed on mac os there is no problem. The navigation is working.

My original issue is on windows. Could you please try on windows as well?

I definitely have an issue on windows, as when I was working yesterday evening the navigation was broken.
I might try to deploy a fresh windows vm later to check if it is host specific. However in this case something is broken
on my machine and I have no clue what it might be. While when I tried to reproduce the issue
on windows I ended up to remove everything and then reinstall all the tools freshly. This includes the removal of

%LOCALAPPDATA%\.dartServer
%LOCALAPPDATA%\Pub
%APPDATA%\Code
%USERPROFILE%\.vscode
<flutter_git_path>\flutter\bin\cache

[DanTup]

@tupos good spot. You're right, I can repro on Windows. My feeling is that it may be related to a mismatching of the casing of drive letters in paths:

The open file has a lowercase drive letter and that doesn't match what the server is using, so I think it's failing to realise that this file should be analyzed in the context of the parent Flutter project, and is analyzed with the Dart one, which cannot resolve package:flutter.

This is an issue that's come up before (#28895) and a complete fix is complicated, but there were some attempts to normalize drive letters to the same casing to avoid this - I'll see if I track down why that doesn't handle this case.

[DanTup]

@tupos is it possible you could test a fix for me using the pre-release version of the Dart extension?

You can switch to the pre-release versions of the extensions in VS Code by going to the Extensions section, finding Dart and clicking the button shown in the screenshot below.

The version with my change is v3.59.20230207. It might take 10-20 minutes to show up due to VS Code marketplace caching (edit: it has showed up and installed for me now).

[tupos]

@DanTup So I installed the pre-release version of the dart extension and the navigation is working on windows as well.

Thanks a lot for a quick fix.

[DanTup]

Great, thanks for confirming! Assuming no issues come up, it'll be included in the next stable release of the extension. If you hit any issues with the pre-release versions in the meantime, please file issues at https://github.com/Dart-Code/Dart-Code.

[srawlins]

Thanks a million, @DanTup !!

[DanTup]

I'm slightly less sure about this fix now. When investigating this, I had remembered that we'd always uppercased drive letters to avoid this issue, and while testing I saw this wasn't happening and thought VS Code's Uri.file().toString() had changed behaviour recently.

However, with a little more digging I found that the drive-letter-casing-normalisation was never happening for LSP, so it's likely this behaviour/bug has been around a long time.

It's very possible that whether it occurs depends on some other factor outside of our control (for example, the casing of the drive letter in the cwd when pub get was run). Therefore it's possible that this "fix" could also change things negatively for some users if packages had resolved with lowercase drive letters before.

I'm going to leave it in for now (since it improved things for both of us, and on my Windows 11 PC, I was unable to change the cwd in a terminal to have a lowercase drive letter - so I feel like an uppercase one should at least be more common), however if issues come up from pre-releases users closer to release (or stable users after a release) it's possible this will need to be reverted in a patch and we may need to look more at fixing the underlying issue (which is both Dart-Code and the analysis server not handling case-insensitive paths in the way that they really should).

(@bwilkerson FYI... I've looked at this in the past and concluded it's rather tricky - not just technically, because also because the rules for LSP are not clearly defined and VS Code (incorrectly) bases case-sensitivity decisions on platform and not the actual case-sensitivity of the platform (although I expect in the large majority of cases this works out correct).