Debugger SetVariableRequest support

[rkeithhill]

VSCode added the ability to set a variable in the debugger’s Variables window as long as a debug extension declares support for such a feature. I’m currently working on adding that support to PSES. But a question has cropped up that I’d like to get your feedback on. Given that a variable in your script is type [int] at runtime, would you expect the debugger to “strictly” convert a “new value string” (you typed into the UI) to type [int] and fail if not convertible? Or would you expect it to change the type if necessary? That is, if you changed the value of $i (type int) to “42a” should that fail or set the value to [string] “42a”? Would that be weird?

Where the ability to change type comes in handy is when you have an optional parameter $p that is initially set to $null (no type). Setting that to string “Foo” or int 42 seems like something you’d want (which will set the type to [string] or [int] in this case). And I think you would want to be able to set the value back to $null – wiping out the previous type. There are also variables declared like [int]$i. Should the debugger allow the type to be changed for a variable declared as strongly typed? I lean towards not changing the type – assuming I can tell at runtime the variable was declared like that (presence of ArgumentTypeConverterAttribute?).

I guess I have a bit of VS bias where it doesn’t allow you to change types of variables in the debugger but I think you would want this in a debugger for the “type promiscuous” PowerShell.

The attached animated GIF shows using the VSCode UI for this feature:

[dfinke]

I think it should work like PS does.

PS C:\>$a=1
PS C:\>$a.gettype()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Int32                                    System.ValueType

PS C:\>$a="a"
PS C:\>$a.gettype()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     String                                   System.Object

PS C:\> [int]$a=1
PS C:\> $a="a"
Cannot convert value "a" to type "System.Int32". Error: "Input string was not in a correct format."
At line:1 char:1
+ $a="a"

[rkeithhill]

That's the direction I'm leaning but in your first example the parser knows 1 is an int literal. The VSCode debug protocol passes that value as a string "1". I guess we could require that strings passed via this mechanism come across as ""foo"" e.g. in the UI you'd type "foo" for the latter instead of just foo.

And for your third example, I'm still combing through PSVariable to see how I determine that $a is a strongly type [int]. I think it is the presence of the ArgumentTypeConverterAttribute but I need to verify that.

[dfinke]

Is this all in the TypeScript|C# layer? Might be worth trying to infer the datatype when it's passed from vsc, https://github.com/dfinke/ImportExcel/blob/master/InferData.ps1

[daviwil]

Nice work man! Sorry I was slacking on responding to e-mails this weekend, couple of busy days :/

I like the idea of requiring some kind of quotation mark around a numeric value if they really wanted it to be a string. I suppose it could be a little confusing, but nothing some good documentation couldn't avoid. I agree with Doug, makes more sense to be consistent with what you can accomplish in the console while debugging.

[lzybkr]

ArgumentTypeConverterAttribute is what you need - and it makes me so happy I can point you to the source so you can verify:
https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/parser/Compiler.cs#L1407

[rkeithhill]

@lzybkr Thanks!! And yeah, it is way cool that you can now point me to the source. :-)

[paulomorgado]

I haven't used VSCode with PowerShell, but in ISE I can run commands in the session being debugged. If that's allowed in VSCode, I'd go with strict and let the user change the type of the variable with normal commands.

I VS, that would be the immediate window. At, least, for C# development it would.

[rkeithhill]

OK, I think I got this. Added some unit tests and getting close to submitting a PR:

That error, when I try to assign 42a to a strongly typed variable, is the correct error. That's a consequence of allowing PowerShell expressions when setting a variable. That means expressions like 2+2, [Math]::Pi, $outervar + 15, etc all work.

[daviwil]

Really cool that you can actually evaluate an expression there to change the value!

[rkeithhill]

I use Visual Studio as sort of a "gold standard" and was somewhat surprised that VS will evaluate expressions when setting a variable value in the Auto/Locals window.

[daviwil]

I think we can close this now, right Keith?