Extend type definition to include static members and methods.

[Halkcyon]

When using the PowerShell Subexpression operator $() in the contents of a non-literal string "", the contents of the expression should revert to a non-string syntax highlighting.

Currently, parts are highlighted correctly (like type references, variables, and function calls), but member references and function parameters are still highlighted as if they were part of the string.

Replicated in the following:

"An example string generated on $([Net.Dns]::GetHostByName($env:ComputerName).Hostname) at $(Get-Date -Format HH:mm)"

[rkeithhill]

Furthermore, VSCode will now enable quick suggestions support for subexpression inside dq strings if the syntax is tagged with meta.embedded. From 1.18 release notes:

Quick suggestions are disabled inside of strings and comments by default. In some cases, such as in JavaScript template strings, a string or comment may contain blocks of code where quick suggestions should be enabled. Grammars can now hint that VS Code should re-enable quick suggestions by adding a meta.embedded scope on tokens inside of a string or comment:

For example, see https://github.com/Microsoft/vscode/blob/f4b45dcbc93cd1525a3e6cd9fb16f93fbc4a2d58/extensions/php/syntaxes/php.tmLanguage.json

[omniomi]

Using your example GetHostByName is currently scoped as source.powershell -> string.quoted.double.powershell -> interpolated.complex.source.powershell; The complex source scope is effectively a meta scope for everything in a subexpression but is unlikely to be covered by any themes because it's not a legal name so it inherits from the next scope that is covered (string.*).

To address this issue we need to extend to the type definitions which currently only scope what amounts to [*[*]]. Added to this list.

[msftrncs]

Is there anything wrong with using multiple scopes? I was doing some testing with VS Code, applying both scopes, and its a nice improvement to get intellisense inside the subexpressions.

I placed this on the 'interpolation' rule (I technically separated it in to a new 'stringIterpolation' rule so that it doesn't apply to subexpressions outside quoted strings)

"contentName": "interpolated.complex.source.powershell meta.embedded.powershell",

Unfortunately this doesn't appear that it would fix the ability have 'format document' properly format up subexpressions in side expandable strings.

[msftrncs]

I got the best result actually putting 'meta.embedded' on "name" of the pattern rather than "contentName". Dark+, Monokai, and Monokai Dimmed all started coloring subexpressions within strings correctly, including the enclosing parenthesis, but doesn't work for PowerShell ISE theme. For some reason, Abyss must be using the wrong color for meta.embedded, as its set the same color as variable. A few of the others (of all VS Code's stock themes) also used a slightly different text color for meta.embedded, but they all had applied meta.embedded a color.

[msftrncs]

I plan to post a PR per my previous comment.

Does anyone know where the interpolated.complex scope came from?