Skip to content

Conversation

@MartinGC94
Copy link
Contributor

PR Summary

This PR updates the synthetic types used for tab completion and type inference to use PSCustomObject instead of PSObject as the default type name. This will remove the irrelevant and unusable PSObject members like BaseObject and ImmediateBaseObject from the tab completion when working with synthetic types, like: $Data = ls | select Name,Length; $Data.<Tab> and when dealing with custom objects in general: $Var1 = [pscustomobject]@{Test = ls}; $Var1.<Tab>.
This also fixes a minor issue where attempting to wrap a hashtable in a PSObject would remove the hashtable members: $Var1 = [psobject]@{Test = ls}; $Var1.<Tab> so you didn't see members like "keys" and "Count".

PR Context

PR Checklist

{
Members = membersTypes;
if (type != typeof(PSObject))
if (type != typeof(PSCustomObject))
Copy link
Collaborator

@iSazonov iSazonov Apr 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Above in lines 914 and 916 I see two Create() methods with 7 uses - all of them are subject to this change. Please describe all of them in the PR description (not only Hashtable). Perhaps they should also be reflected in the tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has already been described:

This PR updates the synthetic types used for tab completion and type inference to use PSCustomObject instead of PSObject as the default type name.

In other words, every instance where the synthetic type would say it's a "PSObject" has been updated to say it's a "PSCustomObject". This is in line with what we get at runtime, for example:

PS C:\> (ls | select -First 1 Name,FullName).GetType()

FullName                                    BaseType
--------                                    --------
System.Management.Automation.PSCustomObject System.Object

PS C:\>

As for the specific overload references you mention, the first one is exclusively used for Group-Object where the specified typename is Microsoft.PowerShell.Commands.GroupInfo so it's unaffected by these changes.
The second overload is used by Select-Object, Hashtable type inference, and convert expressions where the target type is psobject/pscustomobject. This is where I've made a slight fix so that: [psobject]@{Test = ls} is correctly treated as a hashtable, as the resulting object would just be a standard hashtable with an invisible psobject wrapper around it.

Everything should already be covered by existing tests that were modified for this change, or added as part of the change.

@microsoft-github-policy-service
Copy link
Contributor

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

@microsoft-github-policy-service microsoft-github-policy-service bot added the Review - Needed The PR is being reviewed label Apr 23, 2025
@iSazonov iSazonov added the CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log label Apr 24, 2025
Comment on lines -1947 to +1950
if (type.Type == typeof(PSObject) && type is not PSSyntheticTypeName)
if (type.Type == typeof(PSObject))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the type is not PSSyntheticTypeName check removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added that back in: #21184 so that it could get members for synthetic types but now that synthetic types aren't PSObject anymore, that exclusion is no longer needed.

…sitor.cs

Co-authored-by: Dongbo Wang <dongbow@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log Review - Needed The PR is being reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants