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
We've run into an issue that we've tracked down to formatting std::optional<std::string> with {fmt} in conjunction with the FMT_COMPILE macro. We have observed both incorrect formatted strings and also segmentation faults. I've created a minimal repro case on godbolt with clang trunk and {fmt} trunk:
The issue does not seem to occur if FMT_COMPILE is not used or if the literal passed to it is just "{}", but as soon as the literal contains more than just that, issues crop up when formatting string optionals. I haven't checked if it happens with other std types. It doesn't appear to occur when formatting plain strings, or std::optional<int>, etc...
The documentation suggests this should be a valid use of FMT_COMPILE so I'm submitting this as a bug.
The text was updated successfully, but these errors were encountered:
We've run into an issue that we've tracked down to formatting
std::optional<std::string>
with {fmt} in conjunction with theFMT_COMPILE
macro. We have observed both incorrect formatted strings and also segmentation faults. I've created a minimal repro case on godbolt with clang trunk and {fmt} trunk:https://godbolt.org/z/rE5xadqf1
The issue does not seem to occur if
FMT_COMPILE
is not used or if the literal passed to it is just"{}"
, but as soon as the literal contains more than just that, issues crop up when formatting string optionals. I haven't checked if it happens with other std types. It doesn't appear to occur when formatting plain strings, orstd::optional<int>
, etc...The documentation suggests this should be a valid use of
FMT_COMPILE
so I'm submitting this as a bug.The text was updated successfully, but these errors were encountered: