Skip to content

Fix: Resolve IntelliSense/linter false positive for type_is_unformattable_for #4634

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.

Sign up for GitHub

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

Closed
subashc2023 wants to merge 1 commit into from
Closed

Fix: Resolve IntelliSense/linter false positive for type_is_unformattable_for #4634

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions include/fmt/base.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2148,7 +2148,9 @@ auto get_iterator(buffer<T>&, OutputIt out) -> OutputIt {
}

// This type is intentionally undefined, only used for errors.
template <typename T, typename Char> struct type_is_unformattable_for;
template <typename T, typename Char> struct type_is_unformattable_for {
// Intentionally incomplete - causes compile error when instantiated
};
Comment on lines 2150 to +2153
Copy link

Copilot AI Dec 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment and struct implementation are contradictory. The comment on line 2150 says "This type is intentionally undefined" but the struct is now fully defined with an empty body. The comment on line 2152 says "Intentionally incomplete" but an empty struct is actually a complete type in C++.

Consider updating the comments to accurately reflect the new implementation. For example:

  • Line 2150: "This type is intentionally defined but unused, only for avoiding linter errors."
  • Line 2152: Remove this comment or change to explain that the struct exists only to satisfy linters while compile-time errors are generated via static_assert at usage sites.

Copilot uses AI. Check for mistakes.

template <typename Char> struct string_value {
const Char* data;
Expand Down Expand Up @@ -2311,7 +2313,8 @@ template <typename Context> class value {
FMT_CONSTEXPR value(const T&, custom_tag) {
// Cannot format an argument; to make type T formattable provide a
// formatter<T> specialization: https://fmt.dev/latest/api#udt.
type_is_unformattable_for<T, char_type> _;
static_assert(sizeof(T) != sizeof(T),
"Type is not formattable. Provide a formatter<T> specialization.");
Comment on lines +2316 to +2317
Copy link

Copilot AI Dec 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The static_assert condition sizeof(T) != sizeof(T) is technically always false, which is the intended behavior. However, this is a known pattern that may be deprecated in C++23 and beyond. Consider using std::false_type::value or a more explicit dependent false pattern like sizeof(T) && false to make the intent clearer and ensure future compatibility.

Additionally, consider whether the condition should be dependent on the template parameter to avoid potential issues with immediate evaluation. A safer alternative would be:

template<typename> struct always_false : std::false_type {};
static_assert(always_false<T>::value, "Type is not formattable. Provide a formatter<T> specialization.");

Copilot uses AI. Check for mistakes.
}

// Formats an argument of a custom type, such as a user-defined class.
Expand Down
Loading