[Bug][tcgc] getSdkUnion would merge underlying enum members to top level

[MaryGao]

Describe the bug
When we adopt to the latest tcgc our two cases failed and we found that

• Sometimes the getSdkUnion could return correct isFixed value like Case 2 but sometimes it can't like Case 1
• Also for union of EnumA | EnumB tcgc would flatten all underlying enums into top level

TCGC are supposed to provide consistant isFixed information, otherwise it would be a big issue for JS because RLC didn't adopt tcgc but Modular does. So it would introduce type inconsistancy between them and finally fails the compile process.

Also I think current behavior for prompting members to top level is debetable. It would lose the name info which may be useful for emitters.

Case 1: Nullable enum

enum Color {
  Color1: 1,
  Color2: 2
}
model Test {
  color: Color | null;
}
op read(@body body: Test): void;

Case 2: EnumeA | EnumB

 enum LR {
  left,
  right,
}
enum UD {
  up,
  down,
}

model Test {
  color: LR | UD;
}
op read(@body body: Test): void;

[tadelesh]

TCGC get this info from two places, first is isFixed (code) from @fixed decorator, second is the open property in UnionEnum type (code). I think current problem should mainly from losing information for hierarchy union.

[lirenhe]

@MaryGao, in JS, do we have a workaround for this issue?

[MaryGao]

@MaryGao, in JS, do we have a workaround for this issue?

I don't think we have a quick workaround here because our modular logic has serveral dependencies with isFixed column, currently we just fallback to tcgc dev.17 version.

Currently RLC leverages the isFixed in core and for modular we leverages the tcgc. The inconsistancy would exist if we have gaps between core isFixed and tcgc.

[iscai-msft]

Here we are only calling what typespec and typespec-azure are providing us, like @tadelesh said. Talked with @lmazuel and for case 1, it is by design that isFixed is still returning False. The tsp team will change the behavior of isFixed once everyone has moved to adopting "union with base type is extensible enum"

[lmazuel]

Both your cases are by design and work as expected:

enum Color {
  Color1: 1,
  Color2: 2
}

is an extensible enum. We do have plan to switch this to fxed enum, when we can confirm all emitters are treating the union correctly

Flattening enum values is by design as well.

@MaryGao I'm worried to be honest of what "workaround" you would do here, since both are by designed. I'm closing this issue, and we can confirm this off-line.

[tadelesh]

The inconsistency is come from the flatten. TCGC uses getUnionAsEnum to see if a union is an enum, and this function does the judgement from the flattened elements view, because TypeSpec type system's UnionEnum type could has child union or enum element. Since client type system could only has union or enum type, I made a fix to change back to union if union has union or enum variants, regardless of it is an enum with flatten view.

[tadelesh]

JS has workaround for the inconsistency of whether is open for flattened union as enum. Remove Blocking label.