get_path_string used the native or generic string computed by the path
formatter only when converting wchar_t to UTF-8 and fell back to
p.string<Char>() otherwise, so the 'g' specifier was ignored when the
output character type matched path::value_type. On Windows,
fmt::format(L"{:g}", path(L"C:\\foo")) returned L"C:\\foo" instead of
L"C:/foo". Use the passed string in that case, as write_escaped_path
already does.
The year_month_day formatter only filled in tm_year, tm_mon and tm_mday,
so specifiers that depend on the weekday or the day of the year (%a, %A,
%u, %w, %j, %U, %W, %V, %G, %g) were formatted from zero-initialized
fields, e.g. every date was printed as a Sunday. Compute tm_wday and
tm_yday from the date before passing it to the tm formatter.
nested_format_specs::write formatted the body of a padded value into a
temporary buffer using a context of the same type as the outer one. This
only works when the outer context writes to an appender, so FMT_COMPILE
and format_to with other output iterators failed to compile even when no
width was given.
Use a buffer context that takes arguments and locale from the outer
context when the outer context doesn't write to an appender.
Fixes#4949.
Floor the seconds before calling gmtime instead of adjusting tm_sec, and
keep the subsecond remainder in the common duration type, which fixes
overflow for narrow reps such as duration<int16_t, std::micro>.
C only applies the '+' and space flags to signed conversions, so
fmt::sprintf("%+u", 42) should give "42" like printf does, not "+42".
The same goes for %o, %x and %X.
For numeric alignment write the 0x prefix directly to the output and
subtract it from the width instead of tracking the prefix length
separately. This makes the extra write_padded call and the intermediate
buffer copy unnecessary, restoring write_bytes.
operator= deallocates the destination's storage but leaves it pointing at
the freed block with a stale capacity and size. When the allocator doesn't
propagate and the two allocators are unequal, move_alloc copies into that
pointer rather than taking over the source's storage, so it writes to freed
memory and the destructor then frees the same block again.
Restore the inline buffer after deallocating and before calling move().
EDG over GCC likes to pretend to be GCC in a lot of macros,
but not all. It does not define `__OPTIMIZE__` ever.
So we would erroneously emit pragma optimize `Og`
even in optimized builds.
* Fix null allocator reference in non-propagating move test
* Test ostream chunking with a real buffer
* Initialize the file pointer when constructing a buffer writer
* Enable ASan and UBSan in supported Linux CI builds
* Limit sanitizer CI to recent Clang and GCC configurations
Unify the duplicated trailing-zero computation in write_fixed and remove
the redundant guards around fill_n. Reduce the constexpr branch of
basic_memory_buffer::grow to a single construct loop that uses the
buffer's own allocator.
In tests, drop the MSVC version checks that FMT_USE_CONSTEVAL already
implies, replace a loop computing 2^-900 with the 0x1p-900 literal, and
report high_precision_long_double as skipped rather than passed when
long double is not an extended-precision type.
Hoist the loop-invariant is_constant_evaluated check into a guard, matching
the fill_n overload for pointers. This lets the runtime path return out
directly instead of relying on the scalar fallback being a no-op once n
reaches 0, and leaves the fallback call only in the branch that needs it.
Also cache buf.size() per iteration as buffer::append does, so the fill
pointer is computed after try_resize rather than depending on it not
reallocating.
Fill available appender storage in bulk, continuing across buffer growth and flushes
Preserve the constexpr-compatible scalar fallback
Add testing of large padded sizes
Build format-test.cc with FMT_USE_LOCALE=0 in nolocale-test instead of a
separate test file. This replaces two ad-hoc checks with the whole format
test suite. The locale-dependent tests were guarded by the removed
FMT_STATIC_THOUSANDS_SEPARATOR macro, so the guard never took effect.
Since GCC 16, in Debug (meaning `-O0`) builds,
`-Wmaybe-uninitialized` falsely warns in certain situations where
you convert a pointer to a not-yet-initialized variable to pointer-to-const.
Associated bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127470
Format an enum as its underlying value if the enum is annotated with
fmt::as_underlying, the equivalent of std::format_as_underlying from P4267:
enum class [[=fmt::as_underlying]] color { red = 1, green = 2, blue = 4 };
fmt::format("{:04x}", color::blue); // "0004"
The value is mapped before type erasure via the existing
formatter<T>::format_as hook, as in the std::byte formatter, so it is stored
as a builtin argument and can be used as dynamic width or precision.
Combining the annotation with fmt::as_identifiers is rejected with a
static_assert.
Reuse getsign instead of mapping the sign to a string and let write_bytes'
default_align handle align::none. Also drop the presentation type check:
printf only produces dec, oct and hex for a non-char integral argument
because 'c' converts the argument to the char type.
The tuple formatter had a bespoke trait to keep format_as from producing an
ambiguous specialization. detail::has_format_as already answers that question
and std.h applies it the same way, so move it from std.h to format.h where
ranges.h can see it and drop the extra trait.
Check it with conditional_t rather than &&: is_tuple_formattable must not be
instantiated for types with format_as because for self-referential tuple-like
types that recurses back into formatter selection, and && short-circuits
evaluation but not instantiation.
format.h and std.h suppress Clang warnings for declarations provided by
fmt, but do not restore the previous diagnostic state. Including either
header therefore also hides the corresponding warning in unrelated
consumer code.
Use fmt's existing Clang diagnostic push and pop macros to limit
-Wweak-vtables to format_error and -Wbit-int-extension to the two
_BitInt aliases.
Signed-off-by: Yongqiang Tian <yqtian668@gmail.com>
Both specializations are always parsed while only the selected one is
instantiated. The #else branch it replaces is compiled by no target:
nolocale-test builds src/format.cc, which never reaches chrono.h.
tm_writer takes a locale_ref and the localized flag instead of a std::locale
reference, and resolves the locale the same way numeric {:L} does: classic
unless localized, otherwise the one passed to the formatting function or the
global one. The facet calls are confined to three shims, so with locale
support disabled nothing pulls in std::locale. get_locale, which existed only
to materialize and own a std::locale, is no longer needed.
The std::tm formatter treated a missing locale argument as the classic locale
rather than the global one, and since #4935 routes {:L} on weekday and month
through it, {:L} without a locale argument ignored the global locale for all
calendar types. It now uses the global locale, as numeric {:L} does. Output
with an explicit locale is unchanged. With FMT_USE_LOCALE=0, {:L} no longer
consults the global locale, matching numeric formatting under that option. An
-Os test program loses all 16 of its std::locale and time_put symbols.
formatter<year_month_day>::format passes true to get_locale, so every default
format constructs a std::locale, and tm_writer then compares it against the
classic locale (is_classic_(loc_ == get_classic_locale())). The only thing
written is on_iso_date(), which is pure arithmetic and reads neither loc_ nor
is_classic_.
It is the odd one out among its siblings: formatter<day> and formatter<year>
pass false; formatter<weekday> and formatter<month> pass their localized()
flag. Only year_month_day hardcodes true, and its parse() never sets localized
in the first place.
With FMT_USE_LOCALE=0 this costs more than a copy: the loc.get<std::locale>()
arm of get_locale is compiled out, so it default-constructs instead, capturing
the current global locale in a build that asked for no locale support.
No output change: chrono_test.year_month_day already sets a non-classic global
locale and expects "2024-01-01".
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Don't let ADL pick to_string_view
02bf4d1c disabled ADL for to_string_view by qualifying the is_string trait,
and has_to_string_view and char_t are qualified for the same reason. Two call
sites were left behind: value's string constructor and the write() overload
for types with a string view conversion. Both sit inside fmt::detail, where an
unqualified call adds the argument's own namespace to the overload set.
That splits the two halves of one decision. Both call sites are reached only
through has_to_string_view or char_t, which are defined by the qualified
expression, so ADL can never be needed to satisfy them - it can only add
candidates the gate never considered. When the argument's namespace declares a
to_string_view template, the two tie during partial ordering and the call is
ambiguous:
core.h(2211): error C2668: 'to_string_view': ambiguous call to overloaded
function
note: could be 'string_view N::to_string_view<T>(const T&)' [found using
argument-dependent lookup]
note: or 'basic_string_view<char> fmt::detail::to_string_view<T,0>(const T&)'
Both are reachable. format("{}", x) stores the argument through value's
constructor; to_string(x) passes it to detail::write unmapped, which lands on
the write() overload, as do FMT_COMPILE named fields and
nested_formatter::write_arg. Reverting either line alone breaks the build of
the test that covers it.
This turned up in Microsoft Office, which declares a constrained
to_string_view template next to its own string types. It only breaks where
those types are distinct classes, so the same code compiles on platforms whose
string types are std aliases - the ADL set is namespace std there and picks up
nothing.
One behaviour change worth noting: a non-template to_string_view in the
argument's namespace used to win outright at these call sites, so a type that
satisfies is_std_string_like via find_first_of and data() but has no size()
formatted through ADL and now fails to compile, because the trait only checks
that the qualified overload is viable, not that its body instantiates. That is
the removed extension point going away rather than a new restriction; ADL
to_string_view stopped being supported in 02bf4d1c.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
