-
-
Notifications
You must be signed in to change notification settings - Fork 36
Fix select tests to not presume fallback for formatting #1048
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
Conversation
"src": ".local $sel = {1 :integer select=$bad} .match $sel 1 {{ONE}} * {{variable select {$sel}}}", | ||
"params": [{ "name": "bad", "value": "exact" }], | ||
"exp": "variable select {$sel}", | ||
"exp": "variable select 1", | ||
"expErrors": [{ "type": "bad-option" }, { "type": "bad-selector" }] | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't the result here be nomatch
(we don't say what happens with nomatch
??) and thus result in an empty pattern (and the logo)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Failing to match any pattern is not possible with MF 2.0 because we've not reached consensus on #603. If we end up with a selector that doesn't support selection (as happens here), we select and format the *
pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took some searching (because we say hardly anything about Resolution Errors), but this seems to cover it:
When an error occurs while resolving a selector or calling MatchSelectorKeys with its resolved value, the selector MUST NOT match any variant key other than the catch-all * and a Bad Selector error MUST be emitted.
We probably should be more explicit about what happens in the section on pattern selection. The above text appears in the section on error handling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That section is actually really excplicit, it's just complicated because we ended up doing best-match rather than first-match selection. The bad-selector error is coming from Resolve Selectors step 2.iii.c., selecting the *
variant is due to Filter Variants step 2.i.b.a.
I can't think of any other cases where an error is emitted but the output doesn't contain any fallback strings (or fallback parts, in the case of |
Selection errors can work this way: if such happens, we emit an error and select the |
@eemeli noted:
Yes, we just discussed this. This feels sort of wrong? I'm not sure what the utility of emitting a non-fallback formatted pattern is. Note that with multiple selectors, the |
The changes in #1046 weren't quite enough, as they don't account for this part of the spec:
message-format-wg/spec/functions/number.md
Line 645 in 662076e
That means that the formatting of a placeholder with
select=$bad
does not experience fallback, even if an error is emitted.