Skip to content

Refactor PSMethodInvocationConstraints to make it able to work with types that not available at compilation time but loaded at runtime #16809

@daxian-dbw

Description

@daxian-dbw

Use this issue to track my review comment #12412 (comment) regarding PSMethodInvocationConstraints.GenericTypeParameters.

There are 2 problems with invocation of method with generic arguments today:

  1. For $a.MethodName[type-A]($arg), if [type-A] cannot be resolved at all, there is no good error message on what type name cannot be resolved.
  2. For $a.MethodName[type-A]($arg), if [type-A] can be resolved at run time (new assembly gets loaded or so), it won't be honored, because we only attempt to resolve the type at compilation time in compiler.

It's not a problem for PSMethodInvocationConstraints.ParameterTypes, because for any argument conversion, if we cannot resolve the type when constructing PSMethodInvocationConstrains (namely, the element in ParameterTypes is null), then we will just use the effective argument type in FindBestMethodImpl.

The fix would be to refactor PSMethodInvocationConstraints.GenericTypeParameters somewhat, to allow a compile-time unresolvable type to fall back to TypeOps.ResolveTypeName in FindBestMethodImpl. That method will take care of the type loaded at run time, as well as generating better error message when a type name really cannot be resolved.

Metadata

Metadata

Assignees

Labels

Issue-BugIssue has been identified as a bug in the productResolution-FixedThe issue is fixed.WG-Enginecore PowerShell engine, interpreter, and runtime

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions