Fix ValidateSet with generator in a module#5702
Conversation
The symbol resolver was properly resolving the type to the class definition, but that resolution was ignored at runtime because we used the string instead of the ITypeName - the ITypeName kept the reference to the class definition. Fix PowerShell#5661
| if (ast.PositionalArguments.Count == 1 && ast.PositionalArguments[0] is TypeExpressionAst generatorTypeAst) | ||
| { | ||
| if (TypeResolver.TryResolveType(generatorTypeAst.TypeName.FullName, out Type generatorType)) | ||
| var generatorType = TypeResolver.ResolveITypeName(generatorTypeAst.TypeName, out Exception exception); |
There was a problem hiding this comment.
ResolveITypeName again check iTypeName as TypeName - can we use internal static Type ResolveTypeName(TypeName typeName, out Exception exception)?
There was a problem hiding this comment.
No, you might have something else like a generic or array type instead of a simple type.
There was a problem hiding this comment.
Thanks for clarify!
Should we test these cases too (generic or array)?
There was a problem hiding this comment.
The ast must be fully general which explains why you must use ResolveITypeName here.
In this specific case, it is extremely unlikely anyone would ever use a generic (which should work) or an array (which should be an error), so testing has marginal usefulness.
Add a test that has been skipped in PR #5702
PR Summary
The symbol resolver was properly resolving the type to the class
definition, but that resolution was ignored at runtime because we used
the string instead of the ITypeName - the ITypeName kept the reference
to the class definition.
Fix #5661
PR Checklist
Note: Please mark anything not applicable to this PR
NA.NANA[feature]if the change is significant or affectes feature testsWIP:to the beginning of the title and remove the prefix when the PR is ready.