completions for attribute/type alias's inconsistent.

[msftrncs]

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?

[SeeminglyScience]

@msftrncs The difference is that PSDefaultValue is a type accelerator (a type alias specifically defined in PowerShell itself) for System.Management.Automation.PSDefaultValueAttribute.

Support for that type of completion would need to come from PowerShell itself (this extension just calls PowerShell's CommandCompletion API).

That said, from a purely static point of view, it's not usually possible to tell if a type expression is going to be part of an actual attribute expression. You can only refer to FlagsAttribute as Flags when you're using it as an attribute (e.g. [Flags()]). So unless you've already typed the () it's not clear how you're going to use it.

[msftrncs]

@SeeminglyScience, so you are saying the issue is in PowerShell directly? [ordered] is also a type alias, and that was my point, they are all type alias. Auto completions should all be identical, unless there is some reason they are not.

I've confirmed, the completions are actually coming from PowerShell, I'll try in the PowerShell/PowerShell repository.

[SeeminglyScience]

[ordered] is also a type alias, and that was my point, they are all type alias. Auto completions should all be identical, unless there is some reason they are not.

Logic for ordered in convert expressions is hard coded into the parser, it doesn't actually have a type accelerator defined (e.g. [ordered] doesn't resolve to anything by itself). System.FlagsAttribute is not either, PowerShell's type resolution just allows you to omit the System namespace.

You can use this to see what type accelerators are defined: [ref].Assembly.GetType('System.Management.Automation.TypeAccelerators')::Get

[msftrncs]

I'm not just leaving off system with [flags()]. There must be something that allows PowerShell to find FlagsAttribute from flags. ([flags()] is in the PowerShell Docs for Enum's)

[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.

[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)!