Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

Merged
merged 2 commits into from
Mar 10, 2025

Conversation

eemeli
Copy link
Collaborator

@eemeli eemeli commented Mar 1, 2025

The changes in #1046 weren't quite enough, as they don't account for this part of the spec:

The formatting of the _resolved value_ is not affected by the `select` _option_.

That means that the formatting of a placeholder with select=$bad does not experience fallback, even if an error is emitted.

@eemeli eemeli requested review from aphillips and catamorphism March 1, 2025 22:46
@eemeli eemeli added the test-suite Issue pertains to tests label Mar 1, 2025
Comment on lines 65 to 69
"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" }]
}
Copy link
Member

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)?

Copy link
Collaborator Author

@eemeli eemeli Mar 2, 2025

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.

Copy link
Member

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.

Copy link
Collaborator Author

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.

@catamorphism
Copy link
Collaborator

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 formatToParts). This means that in an environment where lenient error handling can be enabled (i.e. no errors, only best-effort output), it might not be obvious from looking at the output that an error occurred. I don't think that's a big problem, but I wanted to point it out.

@eemeli
Copy link
Collaborator Author

eemeli commented Mar 3, 2025

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 formatToParts).

Selection errors can work this way: if such happens, we emit an error and select the * pattern, which may well format without any error.

@aphillips
Copy link
Member

@eemeli noted:

Selection errors can work this way: if such happens, we emit an error and select the * pattern, which may well format without any error.

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 * pattern (the all-* one) may be a terrible fit. I am not arguing for a change in the tests in the circa-47 timeframe, but maybe we need to discuss it as a WG a bit more. I'll file an issue to track it.

@aphillips aphillips merged commit 33b6482 into main Mar 10, 2025
2 checks passed
@aphillips aphillips deleted the fix-select-more branch March 10, 2025 16:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test-suite Issue pertains to tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants