Skip to content

Fix ambiguous FormatConvertImpl when type has both AbslStringify and AbslFormatConvert#2024

Open
dr-feld wants to merge 1 commit intoabseil:masterfrom
dr-feld:fix/strformat-ambiguous-call
Open

Fix ambiguous FormatConvertImpl when type has both AbslStringify and AbslFormatConvert#2024
dr-feld wants to merge 1 commit intoabseil:masterfrom
dr-feld:fix/strformat-ambiguous-call

Conversation

@dr-feld
Copy link

@dr-feld dr-feld commented Mar 12, 2026

When a type defines both AbslStringify and AbslFormatConvert, calling absl::StrFormat("%v", value) caused a compilation error due to ambiguous overload resolution in FormatConvertImpl.

This fix gives AbslStringify priority over AbslFormatConvert when both are defined, by:

  • Adding !HasAbslStringify<T>::value guard to the AbslFormatConvert overload of FormatConvertImpl
  • Updating ArgumentToConv() to return v conversion char set when both methods are present
    A test is added to verify that AbslStringify is called when both methods are defined.

Fixes #1966

…AbslFormatConvert

When a type defines both AbslStringify and AbslFormatConvert,
FormatConvertImpl overload resolution was ambiguous, causing a
compilation error.

Fix by giving AbslStringify priority over AbslFormatConvert when
both are defined, consistent with the intended use of AbslStringify
as the preferred extension mechanism.

Fixes abseil#1966
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Defining both AbslFormatConvert and AbslStringify leads to ambiguous function call

1 participant