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

Add Duplicate Variant error #853

Merged
merged 3 commits into from
Aug 12, 2024
Merged

Add Duplicate Variant error #853

merged 3 commits into from
Aug 12, 2024

Conversation

eemeli
Copy link
Collaborator

@eemeli eemeli commented Aug 5, 2024

See #847 for context and discussion.

This does not address the questions about identifier normalization also raised in the parent issue; that should be done in a separate PR.

@eemeli eemeli added syntax Issues related with MF Syntax errors Issues related to the errors section of the spec labels Aug 5, 2024
Copy link
Member

@aphillips aphillips left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good start.

spec/errors.md Outdated Show resolved Hide resolved
spec/errors.md Show resolved Hide resolved
spec/syntax.md Outdated Show resolved Hide resolved
@eemeli eemeli requested a review from aphillips August 6, 2024 15:31
Copy link
Collaborator

@catamorphism catamorphism left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable enough

@@ -369,6 +369,9 @@ satisfied:
- At least one _variant_ MUST exist whose _keys_ are all equal to the "catch-all" key `*`.
- Each _selector_ MUST have an _annotation_,
or contain a _variable_ that directly or indirectly references a _declaration_ with an _annotation_.
- Each _variant_ MUST use a list of _keys_ that is unique from that
of all other _variants_ in the _message_.
_Literal_ _keys_ are compared by their contents, not their syntactical appearance.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
_Literal_ _keys_ are compared by their contents, not their syntactical appearance.
_Literal_ _keys_ are compared by their contents, not their syntactical appearance.
Keys are considered the same if they are canonically equivalent.
See [Canonical and Compatibility Equivalence](https://unicode.org/reports/tr15/#Canon_Compat_Equivalence)

Unicode conformance allows (and encourages) implementations to normalize canonically equivalent characters. This is a very common operation when text is input and/or processed. Without this step, there are cases where one implementation would return this error and another would not.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Canonical equivalence looks like a pretty good idea, but we should apply it to all the places where we do such comparisons. But I think that's a separate change from this PR that I explicitly left out:

This does not address the questions about identifier normalization also raised in the parent issue; that should be done in a separate PR.

@macchiati
Copy link
Member

macchiati commented Aug 7, 2024 via email

@aphillips aphillips merged commit 5612f3b into main Aug 12, 2024
2 checks passed
@aphillips aphillips deleted the duplicate-variant-error branch August 12, 2024 16:39
eemeli added a commit to messageformat/messageformat that referenced this pull request Aug 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
errors Issues related to the errors section of the spec syntax Issues related with MF Syntax
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants