sub members (properties/methods) of variables appear different behind an array reference

[msftrncs]

Environment

• Editor and Version: VS Code: 1.25.1
• Your primary theme: Dark+ (with corrections for punctuation inside subexpressions inside strings)

Issue Description

Shouldn't both of these appear equivalent? These are all just accessing a property of an object.

$dir.Extension

$dir[0].Extension

($dir).Extension

obviously there could be a complete expression inside the brackets.

(image doesn't contain the third example line)

Expected Behavior

I would have expected the properties to both be shown in the same dull yellow, but only the first one is, the others are instead white, the default when no scope match occurs.

Using VS Code's Inspect TM Scopes, the first line, results in 'entity.name.function.invocation.powershell' and 'source.powershell', where as the second only has 'source.powershell'.

Fortunately ${dir}.Extension appears correct, but brings up a different issue.

[Jaykul]

This also affects properties and methods chained after method invocations like:

$Credential.GetNetworkCredential().Password

[msftrncs]

I think I found a work-around for this:

Change the 'end' matches for both 'interpolation' and 'interpolatedStringContent' to

            "end": "(\\))((?:\\.(?:\\p{L}|\\d|_)+)*\\b)?",
            "endCaptures": {
                "1": {
                    "name": "punctuation.section.group.end.powershell"
                },
                "2": {
                    "name": "variable.other.member.powershell"
                }

[msftrncs]

also, this for both 'attribute' and 'type':

            "end": "(\\])((?:\\.(?:\\p{L}|\\d|_)+)*\\b)?",
            "endCaptures": {
                "1": {
                    "name": "punctuation.section.bracket.end.powershell"
                },
                "2": {
                    "name": "variable.other.member.powershell"
                }
            },

[msftrncs]

Looks like I went too far with 'iterpolation' … it gets used by string expansion subexpressions, which causes problems with subexpressions in strings. This would need to get separated.

[omniomi]

@msftrncs I am planning to completely overhaul how variables are captured from the ground up (#137) so I don't want to spend a lot of time picking away at the existing captures because the root of the problem is the whole methodology; However, if you'd be willing to prepare a PR in the mean time since it could take me a while we'd be happy to review it/merge it.

There are instructions in the readme on how to build and test the grammars or you can always just submit a PR marked as a WIP and let the CI scripts run the tests for you.

[msftrncs]

@omniomi, I'll try to work that up (relatively new to concept of Git). I can completely understand the goal of overhauling parts, as it becomes evident trying to trace down all the nearly identical behaviors in different parts, dealing with repository object naming logic, etc.... In the meantime, I think I have worked off the major annoyances I have found. It will definitely take me a bit to sort out all the changes I have been making.