You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@FMorschel where is your execution pointers for (1)? If type is also used further down, it will only show on the last instance of the identifier.
For (2), I guess this is where the simple rule of "the last instance of an identifier" doesn't look so good. It's possible for this case we could figure out you're in the else and exclude the other branches, however I don't know if it's guaranteed that a client would give us a completely accurate position of execution and I suspect even if we did that, there may be other cases that do something similar.
Even if we said we'd show against all instances of an identifier, it might still look odd if we show on branches that weren't taken. I think this needs some more thought (and I will try and test out some other languages to see what they do - it's possible this is common).
Yeah, the issue here is really about what we do with branches that we don't know if were taken. Here's a simpler example of the issue:
Here, the analysis server has no idea whether the if condition matched or not, so it has no idea if that instance of i was actually part of executing code.
I think it would be useful to compare other languages that support this feature - I have split this into #5454 as somewhere to discuss.
Is this going to be available with next stable? I wonder what are the differences between VS Code extension provided inline values vs this generic setting debug.inlineValues (which worked way before 3.29)
For variables/parameters, yep! Getters is still behind a flag because I want to be sure we're not being too noisy or triggering lots of side-effects before having that on by default.
I wonder what are the differences between VS Code extension provided inline values vs this generic setting debug.inlineValues (which worked way before 3.29)
When I previously tried it, the VS Code version (which has no understanding of the language) had some awkward quirks, like showing in unrelated functions - see microsoft/vscode#60150. By doing it in the language server, we have more control over where these appear (or don't). We also currently only show the last instance of a given value to try to reduce the noise (for example your screenshot above shows multiple copies value that all have the same value, but confusing are not the value of that variable when execution was that line. When the server provides these, you'd only get the one on line 146.
Just one more question - Will the new annotation (based on language-server) be fed into default VS Code's debug feature? Or should I switch to Flutter/Dart-Code setting once it's supported by my Flutter version?
Yep, VS Code will automatically ask the language server for inline values when the server says it supports them. Otherwise (if your setting is on) it will infer them. So there should be nothing to do - you'll just get them from the language server after upgrading.
Activity
DanTup commentedon Feb 27, 2025
This is supported for variables via dart-lang/sdk@2cc6b61, ships in the SDK.
FMorschel commentedon Mar 11, 2025
I have two points to consider here:
watchline:nodeis showing up on a line that was never executed:DanTup commentedon Mar 11, 2025
@FMorschel where is your execution pointers for (1)? If
typeis also used further down, it will only show on the last instance of the identifier.For (2), I guess this is where the simple rule of "the last instance of an identifier" doesn't look so good. It's possible for this case we could figure out you're in the
elseand exclude the other branches, however I don't know if it's guaranteed that a client would give us a completely accurate position of execution and I suspect even if we did that, there may be other cases that do something similar.Even if we said we'd show against all instances of an identifier, it might still look odd if we show on branches that weren't taken. I think this needs some more thought (and I will try and test out some other languages to see what they do - it's possible this is common).
FMorschel commentedon Mar 11, 2025
Ops, the first line in the method already uses it, you are right. Thanks!
Thanks!
FMorschel commentedon Mar 21, 2025
I think it is completely lost on switch cases, never entered neither case here:
DanTup commentedon Mar 24, 2025
Yeah, the issue here is really about what we do with branches that we don't know if were taken. Here's a simpler example of the issue:
Here, the analysis server has no idea whether the
ifcondition matched or not, so it has no idea if that instance ofiwas actually part of executing code.I think it would be useful to compare other languages that support this feature - I have split this into #5454 as somewhere to discuss.
orestesgaolin commentedon Apr 1, 2025
Is this going to be available with next stable? I wonder what are the differences between VS Code extension provided inline values vs this generic setting
debug.inlineValues(which worked way before 3.29)DanTup commentedon Apr 1, 2025
For variables/parameters, yep! Getters is still behind a flag because I want to be sure we're not being too noisy or triggering lots of side-effects before having that on by default.
When I previously tried it, the VS Code version (which has no understanding of the language) had some awkward quirks, like showing in unrelated functions - see microsoft/vscode#60150. By doing it in the language server, we have more control over where these appear (or don't). We also currently only show the last instance of a given value to try to reduce the noise (for example your screenshot above shows multiple copies
valuethat all have the same value, but confusing are not the value of that variable when execution was that line. When the server provides these, you'd only get the one on line 146.orestesgaolin commentedon Apr 1, 2025
That explains it.
Just one more question - Will the new annotation (based on language-server) be fed into default VS Code's debug feature? Or should I switch to Flutter/Dart-Code setting once it's supported by my Flutter version?
DanTup commentedon Apr 1, 2025
Yep, VS Code will automatically ask the language server for inline values when the server says it supports them. Otherwise (if your setting is
on) it will infer them. So there should be nothing to do - you'll just get them from the language server after upgrading.