Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug(genType): @genType @as("0") generates type 0 not "0" #6486

Closed
2 of 5 tasks
iamchanii opened this issue Nov 20, 2023 · 1 comment · Fixed by #6487
Closed
2 of 5 tasks

bug(genType): @genType @as("0") generates type 0 not "0" #6486

iamchanii opened this issue Nov 20, 2023 · 1 comment · Fixed by #6487

Comments

@iamchanii
Copy link

Thank you for filing! Check list:

  • Is it a bug? Usage questions should often be asked in the forum instead.
  • Concise, focused, friendly issue title & description.
  • A minimal, reproducible example.
  • OS and browser versions, if relevant.
  • Is it already fixed in master? Instructions

Hi there! I'm try to using variant interop with ReScript v11-rc.5. here is some snippet from my codes:

@genType
type tabIndex = | @as("0") Activity | @as("1") UserKeyword

And generated js code is fine as hopefully as what I expected

  var match$1 = searchParams.get("tabIndex");
  var tabIndex;
  if (match$1 == null) {
    tabIndex = undefined;
  } else {
    switch (match$1) {
      case "0" :
          tabIndex = "0";
          break;
      case "1" :
          tabIndex = "1";
          break;
      default:
        tabIndex = undefined;
    }
  }

I expect above code should be generate "0" | "1" as string union type, but actually I got 0 | 1 as numeric union type.

export type tabIndex = 0 | 1;
cristianoc added a commit that referenced this issue Nov 20, 2023
There is some special code in the type emitter to take care of poly variants of the form e.g. `#0`, which is represented internally as the string "0".
This conflicts with normal variants annotated with `@as("0")` and such.

This PR resolves the case of numeric poly variants early on, and removes the special casing in the code emitter.

Fixes #6486
cristianoc added a commit that referenced this issue Nov 20, 2023
There is some special code in the type emitter to take care of poly variants of the form e.g. `#0`, which is represented internally as the string "0".
This conflicts with normal variants annotated with `@as("0")` and such.

This PR resolves the case of numeric poly variants early on, and removes the special casing in the code emitter.

Fixes #6486
@cristianoc
Copy link
Collaborator

Good catch.
#6487

cristianoc added a commit that referenced this issue Nov 21, 2023
There is some special code in the type emitter to take care of poly variants of the form e.g. `#0`, which is represented internally as the string "0".
This conflicts with normal variants annotated with `@as("0")` and such.

This PR resolves the case of numeric poly variants early on, and removes the special casing in the code emitter.

Fixes #6486
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants