Import aliases are not included in `textDocument/documentSymbol` response
In the following code
import pandas as pd
df = pd.read_csv('data.csv')
I was expecting pd to show up when I open the Go To Symbols (ctrl/cmd+shift+o), with symbol kind vscode.SymbolKind.Module. Currently it's not included in the symbols list, but when we hover over it, we can see that Pylance understands it's a module
@heejaechang, I think this is because of the following check in SymbolIndexer.collectSymbolIndexData:
if (DeclarationType.Alias === declaration.type) {
if (!options.indexingForAutoImportMode) {
// We don't include import alias for workspace files.
return;
}
Looks like you added this comment a long time ago. Do you remember why we filter out aliases?
Looks like you added this comment a long time ago. Do you remember why we filter out aliases?
if you enable alias in user file, now you need to re-index all files that depends on the file that are changed transtively to do alias deduplication so that we don't show hundred of same symbol aliased all over the user files.
and it showed up as perf hit (user changed 1 file, we reanalyze 20 more files) so we droped alias from user files and don't do transitive re-indexing)
https://github.com/microsoft/pyrx/issues/4199
find all reference doesn't consume indices or indexer so, not sure whether 2 would affect each other.
see related issue - https://github.com/microsoft/pylance-release/issues/5231
This behavior is supported in Pyright 1.1.340+, but as HeeJae pointed out to me, getting this to work in Pylance is more complex because it has a different indexer.
Once this gets merged into Pylance, users can test the behavior by disabling indexing (set python.analysis.indexing to false). With indexing enabled, import aliases will appear in document symbols inconsistently. For example, they will be there until the file is modified/indexed.
The pull from pyright is currently blocked on integrating https://github.com/microsoft/pyright/pull/6519 into Pylance. We may want to bring this change over manually in the meantime to unblock @rebornix.
Notes from discussion with HeeJae:
- Probably don't want to expose the data the Jupyter needs via
textDocument/documentSymbolsbecause the data in that message is displayed in the VS Code UI and therefore we might change how it is displayed (pd (alias)instead ofpd) which could break Jupyter. Instead, if Jupyter confirms that this data satisfies their needs, we should expose it via a custom LSP message so we can ensure that the content stays the same over time. - It would be nice if Pyright and Pylance's document symbols results were the same. If we move to a custom LSP message for Jupyter and don't have time to get import aliases properly showing in Pylance's document symbols, we might consider reverting the change in Pyright.
- Alternatively, we could only expose import aliases in document symbols (not workspace symbols) and change Pylance to use Pyright's implementation for document symbols. Indexing is likely not buying us much in the single-document scenario.
- If we decide to update Pylance's index to include import aliases, we need to consider how alias deduplication plays with that.
- From HeeJae: "if you enable alias in user file, now you need to re-index all files that depends on the file that are changed transitively to do alias deduplication so that we don't show hundred of same symbol aliased all over the user files. and it showed up as perf hit (user changed 1 file, we reanalyze 20 more files) so we dropped alias from user files and don't do transitive re-indexing)"
- Also see HeeJae's comment here about perf implications of alias deduplication in user files.
We decided against doing this. The change I made in pyright has been modified so aliases are only included by the symbol indexer when explicitly requested via indexOptions.includeAliases. They are not included for basic document/workspace symbol requests -- they are currently only included for Jupyter's custom LSP message for gather support.