Correctly handle "true" subtags in enum_keywords macro

[jedel1043]

This PR modifies unicode::Value and the enum_keyword macro to correctly handle true subtags. The added test has an extensive example of the (now fixed) incorrect behaviour.

I think it's important to note that this also slightly changes the semantics of Value itself; previously, something like

let v = Value::new_empty();
v.push_subtag(Some("subtag"));

would output the value subtag, while this PR makes it so that the sentinel subtag true is always considered when pushing a subtag, making the above output the value true-subtag. We could also specialize only enum_keyword to handle this correctly, but it seemed weird to have enum_keyword and Value differ in behaviour.

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

[zbraniecki]

    /// let mut v = Value::default();
    /// v.push_subtag(subtag!("bar"));
    /// assert_eq!(v, "true-bar");

This does feel awkward. Why do we need this? Is that really the intention of LDML or just a letter? What is the value of this heuristic?

[jedel1043]

@zbraniecki I think we would have awkward situations either way, because something like this:

let mut v = Value::from_subtag(Some(subtag!("true")));
v.push_subtag(subtag!("bar"));
assert_eq!(v, "bar");

is also a bit awkward, so facilitating the implementation of enum_keyword seemed better overall.

[robertbastian]

So you only need this if you want to model

enum_keyword!(DummyKeyword {
    ("false" => False),
    ("true" => True(DummyTrueKeyword) {
        ("standard" => Standard),
        ("rare" => Rare)
    })
}, "dk");

But shouldn't that be modeled as

enum_keyword!(DummyKeyword {
    ("false" => False),
    ("standard" => Standard),
    ("rare" => Rare),
}, "dk");

[CLAassistant]

All committers have signed the CLA.

[jedel1043]

@robertbastian That's just an artificial test to check that enum_keyword is working correctly. The rationale for adding this change is because in Boa's Intl we had to patch up the keyword preferences to handle this correctly:

https://github.com/boa-dev/boa/blob/87fded1dea78763a749b1a1395cc22ac2ea02354/core/engine/src/builtins/intl/collator/mod.rs#L121-L123

Definitions like

enum_keyword!(
    CollationNumericOrdering {
        ("true" => True),
        ("false" => False),
}, "kn");

incorrectly parse the True variant as having an explicit "true" subtag, instead of being an empty value. The test is just to ensure "true" gets mapped to the empty value, and "true-standard" doesn't get mapped to the subtag "standard", but to the subtags ["true", "standard"].