labath added a comment.
This looks like a step in the right direction. I trust you won't go on a
reformatting spree of the log messages until we settle on the syntax there. ;)
================
Comment at: include/lldb/Core/ModuleSpec.h:244
+ strm.Format("object_mod_time = {0:x+}",
uint64_t(llvm::sys::toTimeT(m_object_mod_time)));
}
----------------
you can delete the `uint64_t` cast now. It was only there to make this portably
printable.
================
Comment at: include/lldb/Host/FileSpec.h:784
+///
+template <> struct format_provider<lldb_private::FileSpec> {
+ static void format(const lldb_private::FileSpec &F, llvm::raw_ostream
&Stream,
----------------
I am wondering.. what is the preferred style for adding formatting capability.
I sort of assumed that the `format_provider` thingy was reserved for cases
where you had no control over the object being formatted (e.g. because it comes
from a third party library), and that for cases like this we would use the
member format function (or, to put it differently: if we're going to be using
the `format_provider` everywhere, what's the point of having the member
functions in the first place?).
Also, my preference would be to not have the F and D styles for FileSpec. I
think they are redundant, as we have FileSpec::GetFilename and
FileSpec::GetDirectory, and also they are not compiler-enforced --
`Formatv('{0}', fs.GetFilename())` is slightly longer than `Formatv('{0:F}',
fs)`, but if I make a typo in the former one, it will be a compiler error,
while the other one won't. I suppose it could be useful, if one wants to format
say an array of FileSpecs using the array format syntax, but I'm not sure how
often will someone want to do that *and* display only the filenames.
I don't care strongly about any of these things, but I want to know what to
expect.
https://reviews.llvm.org/D27632
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
