find all references on an import statement should list all elements in the file that belong to that package.

[stephane-archer]

import 'package:flutter/material.dart';

find all references on an import statement should list all elements in the file that belong to that package.
(basically, all the errors if I was deleting the line)

[bwilkerson]

The functionality I think you're asking for (being able to find references to declarations that are imported from that library) is reasonable functionality to want.

However, it doesn't seem consistent with the general behavior of 'find all references'. If a user selects a declaration and asks for references it means all references no matter what library they happen to be in. If they select a reference to something it means the same thing as asking for references to the declaration being referenced.

If we think of an import as a reference to the library being imported (which is consistent with an earlier request to go to the library on 'go to declaration'), the 'find all references' should find all of the places where that library is imported or exported, not the subset of references to imported declarations that happen to be in the library containing the import.

@DanTup Can we implement search commands that would populate the "Search" pane?

[stephane-archer]

I agree that the behavior has to match the tool. So find all references should find the references in the full project.

I'm not sure if there is already a "find reference limited to the current file" in the LSP tool

[DanTup]

@DanTup Can we implement search commands that would populate the "Search" pane?

We can't populate the search sidebar panel, although we can execute commands that have locations as search results (in a peek window) - which is what the "Go to Augmentation" CodeLenses did (in an early prototype):

augmentation.codelens.mp4

The API is fairly basic, we're essentially just returning the locations of code (we can't provide additional fields to control what's displayed, VS Code will just show the portion of code we provide as the range) - but it does match what you'd see for things like Find References.

[FMorschel]

I like the idea of having a command for this. It would work the other way around as Go to Imports.

It could also probably help users like @Wdestroier, who like to know what is being used from each import in a more controlled manner.

[bwilkerson]

So find all references should find the references in the full project.

If you're suggesting that we could enhance "Go to References" and "Find All References" to support clicking on a URI in a directive and finding all of the other directives that reference that URI, I'd be fine with that.

I'm also fine with the idea of adding a "Go to Imported Names" (or something like that) that would display references to the names imported from the specified library. (We do already have something similar in that you can find all references to a given import prefix, but if the same prefix is used for multiple imports it will find all references to the prefix no matter which import added the name to the scope.) Such a command would, however, only be able to find names from a given library, not necessarily which import added the name to the scope, because there can be multiple imports that bring a single name into the scope.

I don't see either of these as high priority features, but they're reasonable feature to have.