Compiler API: A reference to an enum with one value references the enum value

[Gerrit0]

Bug Report

🔎 Search Terms

single member enum, reference types, compiler API

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about symbol references

💻 Code

export enum CoolEnum {
//          ^^^^^^^^ symbol.id = 103
   FOO, 
// ^^^ symbol.id = 104
} 
 
export interface Response { 
    x:  CoolEnum 
//  ^ type.symbol.id = 104
}

If I add a second member to the enum, the symbol references change to work as expected.

export enum CoolEnum {
//          ^^^^^^^^ symbol.id = 103
    FOO,
//  ^^^ symbol.id = 104
    BAR,
//  ^^^ symbol.id = 105
} 
 
export interface Response { 
    x:  CoolEnum
//  ^ type.symbol.id = 103
}

🙁 Actual behavior

When enums have a single value, reference types which point to them have the type's symbol set to the only member of the enum, not to the enum's symbol.

🙂 Expected behavior

When enums have any number of values, reference types pointing to them should point to the enum itself.

[fatcerberus]

Not familiar with the compiler codebase, but my guess is this happens because an enum type is equivalent to the union of its members, similar to how boolean is the same type as true | false. So if there's only one member then CoolEnum and CoolEnum.Foo are in fact the same type.

[andrewbranch]

That’s correct

[andrewbranch]

That said, we do construct two separate copies of the enum type with value 1 in the single member case, one returned for getTypeOfSymbol for the enum declaration symbol and one for the member declaration symbol. This is a little weird.

[andrewbranch]

@Gerrit0 you can try a draft PR that changes this; sometimes we just don’t have great coverage/visibility about what the public checker API returns. If it doesn’t cause any breaks/changes internally we might consider it, but no guarantees.

[Gerrit0]

That said, we do construct two separate copies of the enum type with value 1 in the single member case

Yep... and this is why I think this is probably unintentional/buggy. I might have time to look into this.... in the meantime, how should I go from a ReferenceType to the declaration that the user intended? Symbols seem like they ought to be the way to do this.

[adamviola]

Hey there! Just wondering if there’s any update on this?

Found a few examples of this bug affecting docs in the wild:

VSCode API!!!

• SymbolTag enum has a single member: Deprecated
• CallHierarchyItem.tags is documented to have typeDeprecated[]; expected SymbolTag[]
• Happens a few more times in VSCode API

Adobe PDF Services SDK

• NotifierType enum has a single member: CALLBACK
• Constructor of NotifierConfig is documented to include parameter of type CALLBACK; expected NotifierType

Sendbird Chat SDK

• MessageCollectionInitPolicy has a single member CACHE_AND_REPLACE_BY_API
• MessageCollection.initialize's policy parameter is documented to have type CACHE_AND_REPLACE_BY_API; expected MessageCollectionInitPolicy