-
Notifications
You must be signed in to change notification settings - Fork 579
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.
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
compile with {fmt} v8 #4260
compile with {fmt} v8 #4260
Conversation
👋 Kefu! 👋 |
@tchaikov there is a |
I took a little look at updating libfmt a while ago, but didn't have the bandwidth to figure out what the internal changes are. I think we should wait until we branch v21.1.x to merge (that doesn't need to block changes on this PR). libfmt-devel >=8 isn't in Ubuntu until Jammy (April 21st) and Fedora 35, so we may also need to package it in the oss build. |
thanks for the pointer. sure, will do. |
good to see you here @tchaikov 👋🏽 🚀 |
okay, will add a commit in this PR to package the latest stable version of fmt in |
@BenPope hi Ben, thanks for your review. i just sent all changes related to fmt v8. now the tree compiles just fine with them and some other misc changes (also proposed as PRs). but i still have two questions. could you please shed some lights on them?
|
d945bf6
to
6df86e4
Compare
Ping @BenPope I think this is waiting for your input? |
Thanks @jcsp, I'm aware. |
@tchaikov - thanks for this. I hacked on this a bit - my branch is it: https://github.com/BenPope/redpanda/commits/update-fmt-v8 It could do with some tidy up of the history. I spent quite a while on a big performance regression. |
@BenPope much appreciated! i will fold your changes into my branch with your credits. |
hi Ben, in the latest revision, i
i will squash the related change into a single one after the review. |
I'm seeing a compilation failure, I guess we should wait for #4722
|
@BenPope sure. squashed, rebased and repushed. |
retriggered internal ci |
change since previous revision
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Out internal build and tests have passed.
This will have to be squashed, as it's not worth trying to make all intermediate steps compatible with both v7 and v8, and it will make git bisect easier.
src/v/raft/consensus.cc
Outdated
constexpr auto parse(format_parse_context& ctx) { return ctx.end(); } | ||
template<typename FormatContext> | ||
auto format(const vote_state& s, FormatContext& ctx) const { | ||
const char* str = "unknown"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if strlen
would be called inside fmt
, but it might make sense to use a std::string_view
.
If that seems suitable, then it may be worth inheriting from formatter<std::string_view>
as is done for seastar::sstring
: struct fmt::formatter<seastar::sstring> final : fmt::formatter<string_view>
, to avoid implementing parse
. and to get the formatting options it provides.
01c65fe
to
f532b14
Compare
change since the previous version
|
as fmt v8 started to error if we pass non-constexpr fmt str to fmt::format() and friends * rpc: include ssx/sformat.h early to get the fmt::formatter<seastar::sstring> instantiated before it is implicit instantiated by Seastar library. * storage: specialize fmt::formtter() for recovert_state * r/consensus: specialize fmt::format() for consensus::vote_state * cluster: specialize fmt::format() for feature_state::state * k/fetch: specialize fmt::format() for isolation * cmake: add fmt to oss.cmake to be compatible with both v8 and pre-v8 libfmt is not necessary if we could just use the former. and fmt v8 features compile-time fmt_string check, which could help us avoid mistakes like: fmt::format("you have two choices: {} and {}", one_option); * util: Avoid deprecated fmt::format_to overload * ssx/sformat: Update to fmtlib v8 * Inherit formatter from string_view to get formatting * Hack to prefer formatter over operator<< * This is a big performance win * Reimplement sformat for performance * With v7, it was about 2x fmt::format with std::string * It's now on par * Using formatted_size was slower than this implementation * schema_registry/proto: move {io,dp}_error_collector::error() down Signed-off-by: Ben Pope <ben@redpanda.com> Signed-off-by: Kefu Chai <tchaikov@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - thanks @tchaikov !
shall i worry about the test failures? after registering on buildkite, i still have 404 when trying to read any of them. |
Sorry, our builds are private, that was intended for other redpanda-data members. |
Cover letter
now that {fmt} v8 is released. and would be great if we can compile against it. in this changeset
fmt::format()
specialization for better debugging experience.Fixes #ISSUE-NUMBER, Fixes #ISSUE-NUMBER, ...
Release notes