PR Summary

Fix#24982

When a generic type expression is parsed for the second time, the generic type can be found in cache, and hence the symbol resolver won't go through the code path to resolvegenericTypeName.TypeName, which represents the generic type definition. Therefore, unlike the first-time parsing, the cached type forgenericTypeName.TypeName won't be set during the symbol resolving process for the second parsing.

However, the type resolution inTypeName.GetReflectionType() doesn't work for a generic type definition in most cases, for example, when the generic type expression is[System.Collections.Generic.List[string]],genericTypeName.TypeName will be aTypeName instance with the full nameSystem.Collections.Generic.List which will fail to be resolved. That's why the second time you parse the same generic type expression,genericTypeName.TypeName.GetReflectionType() will return null.

WhygenericTypeName.TypeName can be resolved in the first-time resolution ofgenericTypeName, but doesn't work when directly callinggenericTypeName.TypeName.GetReflectionType()? That's because for the former, withinVisitGenericTypeName(...), it uses aTypeResolutionState instance as the resolution context, which is constructed with the information from thegenericTypeName (seecode here). But when directly callinggenericTypeName.TypeName.GetReflectionType(), it doesn't have that information and thus cannot use the same/equivalentTypeResolutionState instance as the context for type resolution.

The fix is to pass the generic argument count toTypeName when constructing aGenericTypeName instance, so that theTypeName instance can try resolving with an alternate name (i.e.typename`<n>) when the original name fails to resolve.

The changes also fix another issue:

Before: assembly-qualified name[System.Collections.Generic.List[string], System.Private.CoreLib] cannot be resolved.
After:[System.Collections.Generic.List[string], System.Private.CoreLib] can be resolved as expected.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all.h,.cpp,.cs,.ps1 and.psm1 files have the correct copyright header
• This PR is ready to merge and is notWork in Progress.
  • If the PR is work in progress, please add the prefixWIP: or[ WIP ] to the beginning of the title (theWIP bot will keep its status check atPending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    - [ ] Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively