You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
And a format call of fmt::format("{}=", StringAnswer());.
In parse_format_specs, it points to }=. For the first iteration of "Parse fill and alignment", p will point to =. The = is treated as an ALIGN_NUMERIC alignment specifier, and the specs_checker handler will throw an exception when on_align is called because the type is not a numeric type.
Adding this check
if (*it == '}')
return it;
to the very beginning of parse_format_specs fixes this issue and all existing tests pass. It seems like it doesn't (mostly) change the behavior in other scenarios, but I'm puzzled by this test, because I don't see how c could have a value of } except in cases like this. And since my proposed change just seems like such an obvious check since it seems like it would have a high rate of being true most of the time, I feel like I must be missing something. Otherwise this would have been a PR and not an issue.
The text was updated successfully, but these errors were encountered:
Good catch, the on_align shouldn't be called here. Moving it after the check in question will solve the problem, but you are right, the check probably belongs at the beginning of the function. Fixed in e2cd521.
Assuming this type and formatter:
And a format call of
fmt::format("{}=", StringAnswer());
.In parse_format_specs,
it
points to}=
. For the first iteration of "Parse fill and alignment",p
will point to=
. The=
is treated as anALIGN_NUMERIC
alignment specifier, and thespecs_checker
handler will throw an exception whenon_align
is called because the type is not a numeric type.Adding this check
to the very beginning of
parse_format_specs
fixes this issue and all existing tests pass. It seems like it doesn't (mostly) change the behavior in other scenarios, but I'm puzzled by this test, because I don't see howc
could have a value of}
except in cases like this. And since my proposed change just seems like such an obvious check since it seems like it would have a high rate of being true most of the time, I feel like I must be missing something. Otherwise this would have been a PR and not an issue.The text was updated successfully, but these errors were encountered: