Skip to content

variant with @tag, inline record payload, and duplicate custom tag compiles / produces unsafe code #7438

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

Closed
3 of 5 tasks
illusionalsagacity opened this issue May 7, 2025 · 1 comment · Fixed by #7441
Closed
3 of 5 tasks
Milestone

Comments

@illusionalsagacity
Copy link
Contributor

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

When using a @tag variant type with an inline record definition, we lose the error calling out a duplicate tag: "This untagged variant definition is invalid: Duplicate literal foo."

Here's an example with a boolean tag but this also does not produce the compiler error for ints / strings in the playground link

@tag("type")
type ex =
  | @as(true) True({data: string})
  | @as(false) False({data: unit})
  | @as(false) Third({data: unit, foo: string})


let parse = value => switch value {
  | True({data}) => Console.log(data)
  | False(_) => Console.log("false")
  | Third({foo}) => Console.log2("foo: ", foo)
}

https://rescript-lang.org/try?version=v12.0.0-alpha.10&module=esmodule&code=AIFwhg5gFARCCeAHApjAlAKASgBAZxACcBLAOwgFEAPHAXgxxwB8dgw9YAzAe2-RwAqhAK7IoAbwAmYcAC58RMhAC+mRizYcYAIzCF+AMTAAbPGKkyw84aWIhVDZq3Zde-AQAtihSROlycGzsAGhwebnkCEnIHDAxQSFhsVExknG1eY2o6Rw0XIlE0QRFzfysFaJU1J00oThMzIqNTUstrW3tqvI56lqLPb18LAKCQUPDIxRjMePBoOCQUrEWcMhBs+nVnDgBGfpK-NoqlBy3agCYmhtaRjtOalz3BLx9D25Cw3knK2ONkEBwiD0ZjoOCgADcTKJvkpqEVaAA+fAAdzsAGMPDhIcZRDhxLliqI3mBVHQkQBhbikPDcP4AOmM3GgZS6OGaZigAH14RSqTT6Yz5r0zOgCQNXuJwqTEThKdTacgGUzzq4IjgYONeJhlHE-gCgYQzOdQRCoch5BlaXCySj0Zjsbj8VshEThiSebK+QqlczLKz2WJuTa5fzFYKuNdRc6XkMpR6Q97BSqYBN1ZruNrdf9AcDkABmE0O82rUjrKgevCokAYrFmvFig5u6W8+UCplQFkEgNc+NettCyOs8Wx3jNz2tsPK1XyDWfDMYZRAA

@cristianoc
Copy link
Collaborator

Looks like the issue is variants with payloads, even without the @tag, where this type checks but the two representations are identical.

type ambiguous =
  | @as("foo") A(int)
  | @as("foo") B(int)

let a = A(1)
let b = B(1)

@zth zth added this to the v12 milestone May 7, 2025
cristianoc added a commit that referenced this issue May 8, 2025
Fixes #7438

In variant definitions without payloads, an error is reported if two cases have the same literal `@as(literal)`.
The check so far was missing for cases with payload, where the literal goes into the tag.
However it's perfectly possible to use the same tag in a case without payload, and one with payloads, as the two representations don't overlap.
cristianoc added a commit that referenced this issue May 8, 2025
Fixes #7438

In variant definitions without payloads, an error is reported if two cases have the same literal `@as(literal)`.
The check so far was missing for cases with payload, where the literal goes into the tag.
However it's perfectly possible to use the same tag in a case without payload, and one with payloads, as the two representations don't overlap.
cristianoc added a commit that referenced this issue May 8, 2025
Fixes #7438

In variant definitions without payloads, an error is reported if two cases have the same literal `@as(literal)`.
The check so far was missing for cases with payload, where the literal goes into the tag.
However it's perfectly possible to use the same tag in a case without payload, and one with payloads, as the two representations don't overlap.
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.

3 participants