Add type inference for functions without OutputType attribute and anonymous functions #21127

MartinGC94 · 2024-01-22T01:26:07Z

PR Summary

This adds type inference for functions where the OutputType attribute hasn't been filled out and for anonymous functions.
This allows tab completion to work like you would expect in situations like:

function MyFunction
{
    [pscustomobject]@{Property1 = "Hello"; Property2 = "Hi"}
}
MyFunction | Select <Tab>
# And also:
& {[pscustomobject]@{Property1 = "Hello"; Property2 = "Hi"}} | Select <Tab>

PR Context

PR Checklist

…nymous functions

MartinGC94 · 2024-01-22T18:36:26Z

I've got 2 test failures that I'm not sure how to handle.
1: Infers type from variable with AllowSafeEval it fails because it relied on the idea that type inference wouldn't be able to infer the type of a function with no OutputType defined. With that limitation removed, I'm not sure how to test that AllowSafeEval works.
2: Should infer output from function without OutputType attribute (one of the tests I added) it seems to fail because the pseudobinding fails when running the InferTypeOf method. It works fine when tab completing though. The easiest fix for me would be to just add a tab completion test instead, but if there is a way to make it work the same as the rest of the type inference tests then that would be ideal.

-Edit: Fixed my own test by moving the function definition outside the member invocation because the ExportVisitor doesn't visit child nodes of member invocations.

pull-request-quantifier-deprecated · 2024-01-23T12:48:02Z

This PR has 16 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +16 -0
Percentile : 6.4%

Total files changed: 2

Change summary by file extension:
.cs : +10 -0
.ps1 : +6 -0

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-03-15T19:49:29Z

This PR has 16 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +16 -0
Percentile : 6.4%

Total files changed: 2

Change summary by file extension:
.cs : +10 -0
.ps1 : +6 -0

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-03-15T20:15:44Z

This PR has 17 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +17 -0
Percentile : 6.8%

Total files changed: 2

Change summary by file extension:
.cs : +10 -0
.ps1 : +7 -0

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

…r Object

iSazonov · 2025-02-26T13:24:02Z

@MartinGC94 Please resolve merge conflicts and rebase.

iSazonov · 2025-02-27T09:15:14Z

As for failed test. I see OutputType attribute in Get-Process hasn't parameter sets. So I guess with the change we take all types from the attribute instead of doing type inference based on real objects.

MartinGC94 · 2025-02-27T16:27:41Z

I figured out a way: I can just hide it behind Invoke-Expression and as long as we don't try to make the type inference for Invoke-Expression work, the test will run.

src/System.Management.Automation/engine/parser/TypeInferenceVisitor.cs

iSazonov · 2025-02-28T04:13:56Z

test/powershell/engine/Api/TypeInference.Tests.ps1

+        # Invoke-Expression is used to "hide" Get-Process from the type inference.
+        # If the typeinference code is updated to handle Invoke-Expression, this test will need to find some other way to set $p
+        # so that the type inference can't figure it out without evaluating the variable value
+        $p = Invoke-Expression -Command 'Get-Process'


Can we use the pattern

PowerShell/test/powershell/engine/Api/TypeInference.Tests.ps1

Lines 1569 to 1575 in 8733c17

Describe "AstTypeInference tests" -Tags CI {

It "Infers type from integer with passed in powershell instance" {

$powerShell = [PowerShell]::Create([RunspaceMode]::CurrentRunspace)

$res = [AstTypeInference]::InferTypeOf( { 1 }.Ast, $powerShell)

$res.Count | Should -Be 1

$res.Name | Should -Be 'System.Int32'

}

No because the type inference based on the variable runtime value is a last resort: https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/parser/TypeInferenceVisitor.cs#L2485
The regular type inference will still see the variable being assigned by the command Get-Process and hence, use the output type defined there.
I think the only way to make the test fully robust is to make a test specific Get-Process2 cmdlet without output types defined so that the type inference has no way of finding out the value without the SafeEval.

iSazonov · 2025-02-28T13:10:11Z

@MartinGC94 Please resolve merge conflicts.

iSazonov · 2025-02-28T15:22:28Z

/azp run

azure-pipelines · 2025-02-28T15:22:43Z

Azure Pipelines successfully started running 2 pipeline(s).

microsoft-github-policy-service · 2025-02-28T17:49:25Z

📣 Hey @MartinGC94, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms

Add type inference for functions without OutputType attribute and ano…

08a1424

…nymous functions

MartinGC94 requested a review from daxian-dbw as a code owner January 22, 2024 01:26

pull-request-quantifier-deprecated bot added the Extra Small label Jan 22, 2024

Use the correct property.

c6af115

MartinGC94 added 2 commits January 23, 2024 13:43

Prevent infinite loop when a function calls itself.

b4bfcf8

Use a default value instead of constructor

5021313

microsoft-github-policy-service bot added the Review - Needed The PR is being reviewed label Jan 30, 2024

Merge branch 'PowerShell:master' into ImproveCmdTypeInference

aa25a8b

Fix test

978db3e

MartinGC94 and others added 3 commits September 4, 2024 13:41

Merge branch 'PowerShell:master' into ImproveCmdTypeInference

5604fd9

Merge branch 'PowerShell:master' into ImproveCmdTypeInference

fb5a8d5

Also infer script commands with an output type declared as PSObject o…

73c3bcd

…r Object

microsoft-github-policy-service bot removed the Review - Needed The PR is being reviewed label Feb 26, 2025

Merge branch 'master' into ImproveCmdTypeInference

bf1f636

MartinGC94 requested a review from SeeminglyScience as a code owner February 26, 2025 13:59

This comment was marked as outdated.

Sign in to view

iSazonov self-assigned this Feb 26, 2025

iSazonov added the CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log label Feb 26, 2025

Hide Get-Process with Invoke-Expression

d46e38d

This comment was marked as outdated.

Sign in to view

iSazonov reviewed Feb 27, 2025

View reviewed changes

src/System.Management.Automation/engine/parser/TypeInferenceVisitor.cs Show resolved Hide resolved

src/System.Management.Automation/engine/parser/TypeInferenceVisitor.cs Show resolved Hide resolved

Add comments

6694fb4

iSazonov reviewed Feb 27, 2025

View reviewed changes

src/System.Management.Automation/engine/parser/TypeInferenceVisitor.cs Show resolved Hide resolved

Update comment

8733c17

This comment was marked as outdated.

Sign in to view

iSazonov reviewed Feb 28, 2025

View reviewed changes

Merge branch 'master' into ImproveCmdTypeInference

e57e558

iSazonov approved these changes Feb 28, 2025

View reviewed changes

iSazonov enabled auto-merge (squash) February 28, 2025 15:22

iSazonov merged commit 33ed509 into PowerShell:master Feb 28, 2025
39 of 41 checks passed

MartinGC94 deleted the ImproveCmdTypeInference branch February 28, 2025 18:28

	Describe "AstTypeInference tests" -Tags CI {
	It "Infers type from integer with passed in powershell instance" {
	$powerShell = [PowerShell]::Create([RunspaceMode]::CurrentRunspace)
	$res = [AstTypeInference]::InferTypeOf( { 1 }.Ast, $powerShell)
	$res.Count \| Should -Be 1
	$res.Name \| Should -Be 'System.Int32'
	}

Add type inference for functions without OutputType attribute and anonymous functions #21127

Add type inference for functions without OutputType attribute and anonymous functions #21127

Uh oh!

Conversation

MartinGC94 commented Jan 22, 2024

PR Summary

PR Context

PR Checklist

Uh oh!

MartinGC94 commented Jan 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 23, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Mar 15, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Mar 15, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

iSazonov commented Feb 26, 2025

Uh oh!

This comment was marked as outdated.

This comment was marked as outdated.

iSazonov commented Feb 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MartinGC94 commented Feb 27, 2025

Uh oh!

This comment was marked as outdated.

This comment was marked as outdated.

Uh oh!

Uh oh!

Uh oh!

This comment was marked as outdated.

This comment was marked as outdated.

iSazonov Feb 28, 2025

Choose a reason for hiding this comment

Uh oh!

MartinGC94 Feb 28, 2025

Choose a reason for hiding this comment

Uh oh!

iSazonov commented Feb 28, 2025

Uh oh!

iSazonov commented Feb 28, 2025

Uh oh!

azure-pipelines bot commented Feb 28, 2025

Uh oh!

Uh oh!

microsoft-github-policy-service bot commented Feb 28, 2025 • edited by unfurl-links bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

MartinGC94 commented Jan 22, 2024 •

edited

Loading

iSazonov commented Feb 27, 2025 •

edited

Loading

microsoft-github-policy-service bot commented Feb 28, 2025 •

edited by unfurl-links bot

Loading