completions for attribute/type alias's inconsistent.

System Details

• Operating system name and version: Win 10 1809
• VS Code version: 1.33.1 (user)
• PowerShell extension version: 2.0.2
• PowerShell: 6.2.0

Issue Description

try: Enter [PSDefaultValue], note the completion suggestion PSDefaultValueAttribute, accept the completion, the value inserted is PSDefaultValue. This is good. Enter [Flags], note the completion suggestion FlagsAttribute, accept the completion, the value actually inserted is System.FlagsAttribute. I expected just Flags. Similar result for [Ordered]. EDIT: [PSCustomObject] offers PSObject and a snippet for ‘PSCustomObject’. Accepting the PSObject actually inserts pscustomobject which is kind of confusing.

Why the difference between the completions for these objects?

[rjmholt]

@SeeminglyScience has already covered all the important points here, but to summarise:

• PowerShell has a pretty obvious algorithm for resolving/completing type names in the [...] syntax
• But this is complicated by two fallback rules when immediate type resolution fails:
  • It prepends System. implicitly and looks again (notice that [object] isn’t a type accelerator)
  • When the [...()] attribute syntax is used, it will also append Attribute and look again
• Then there are type accelerators (like [psmoduleinfo] or [semver]), although a lot of these would already work with the implicit System. (like [uri], [version] and [char])
• Then there are some things that are essentially pseudo type accelerators, which may or may not reference a type (e.g. [ordered] doesn’t but [psobject] does) but have specific semantic meaning. [ref] is an interesting case here because it looks like a cast, but is used more like an attribute in C# (it works fine as a type accelerator though).

These make life hard because the completion API has the naive assumption that type accelerators can be uniquely represented by their type name, but:

• [psobject] and [pscustomobject] both point to the same type (even though they do different things)
• [ordered] points to no type at all (it’s not actually a type accelerator even though it’s perfectly suited to be one), so you don’t even get a completion for it (even in the PowerShell console)!

[SeeminglyScience]

When PowerShell expects that the type should resolve to an Attribute, it will append Attribute to the type name if resolution fails without it.