Skip to content

Conversation

@MartinGC94
Copy link
Contributor

PR Summary

Fixes completion of variables that have been assigned with an attribute so they correctly show up in scenarios like:

[ValidateNotNull()]$Var1 = ls
$Var<Tab>

This also fixes the tooltip for variables with multiple type constraints so they show up with the applicable type constraint so [string] [int] $Var1 = 2 correctly shows up as a string due to string being the first type constraint. Before this they wouldn't even be completed.

PR Context

PR Checklist

@iSazonov iSazonov added the CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log label Feb 14, 2025
{
Type lastAssignedType = assignmentStatementAst.Right is CommandExpressionAst commandExpression
? GetInferredVarTypeFromAst(commandExpression.Expression)
: null;
Copy link
Collaborator

Choose a reason for hiding this comment

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

  1. We can use only CommandExpressionAst for type inference? What other types can be in assignmentStatementAst.Right? I see GetInferredVarTypeFromAst() can process another types.
  2. null - no useful default we can use?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

All the types handled by GetInferredVarTypeFromAst() are wrapped in a CommandExpressionAst. Other possible types include if/else statements, loops, etc. while GetInferredVarTypeFromAst() could get updated to handle this, it's out of scope for this PR.
It's also worth keeping in mind that the original goal of this Ast finder was also just to do a quick and dirty Ast analysis without slowing down variable completion too much. The type inference is only used for the tooltip so I intentionally left out stuff like type inference from commands as that could potentially take several seconds (if not minutes) if many modules need to be imported.

As for useful defaults: I can't think of any. I mean I guess I could add [System.Object] for the rest, but that's not a particularly useful tooltip.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Other possible types include if/else statements, loops, etc. while GetInferredVarTypeFromAst() could get updated to handle this, it's out of scope for this PR.

If it makes sense to improve in future, I'd prefer to use case expression pattern with a todo comment for null default about types we can process in future.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

"If it makes sense" is subjective. If it was up to me alone I'd leave it exactly like it is now as it was never meant to be a comprehensive type analysis.

@iSazonov
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@iSazonov iSazonov self-assigned this Feb 18, 2025
@iSazonov iSazonov enabled auto-merge (squash) February 18, 2025 09:48
@iSazonov iSazonov merged commit b565679 into PowerShell:master Feb 18, 2025
39 of 41 checks passed
@microsoft-github-policy-service
Copy link
Contributor

microsoft-github-policy-service bot commented Feb 18, 2025

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

🔗 https://aka.ms/PSRepoFeedback

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants