Name resolution: report interfaces, report type arguments #15628
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the second attempt of #14773.
The goals are:
Reporting both symbols and type arguments may be useful for IDE features.
There're some issues, though. First, the name resolution and reporting of generic symbols is done earlier than type arguments are checked and available for reporting. If we report the types again later, when the needed info is ready, then we'll get duplicated symbol uses that will be different in the type arguments and range. If we remove the type arguments range (and that's what FCS clients often do in an ad-hoc ways), then we can use a special API to report the symbol usage and to replace the previously reported symbol at the range. This replacing API was previously only used in type providers analysis and it was implemented badly performance-wise: it went through all the reported items and tried to remove items at the range from the reported symbol and method group lists. Using that approach would be a no-go for type checking of all the type applications in a file. I've changed the implementation of the
CallNameResolutionSinkReplacing
, so it tries to find the last reported item at the range and replaces it in place. It will add a new item if no previously reported item is found.What we can improve in the reporting in general?
endPos
/range
What can be improved for making changes easier:
We can extract the subsequent work notes to a separate issue.