Instead of having the Error class (which is in Utility) know about logging (which is in Core), it seems more appropriate to put all logging code together, and teach Log about errors rather than teaching Error about logs. This patch does so.
Details
Diff Detail
Event Timeline
I'm not opposed to this patch, if people really want it, but I don't really see the value of this macro.
Why couldn't I write
LLDB_LOG(log, "foo: {0}", error);
instead of
LLDB_LOG_ERROR(log, error, "foo");
Am I missing something?
As for the modules part, I assumed the Log class will end up in the lowest layer also. I intended to move it there after I am done with it, but we can do it sooner if that is stopping you from doing anything. ( I do agree that it makes sense to reverse the dependency though).
I realize the functionality would add a "error: " prefix if it wasn't there, but it seems like we could add this as a formatting option of the lldb_private::Error class? Then we can just switch the logging code to put the error in as a log item and add the extra flag to ensure we print "error:" it is isn't already prefixed with that?
I'm all for making it simpler. The reason I did it this way is that I wanted to keep the exact same syntax as before to minimize the impact of the change. It's rather confusing, but suppose you have these two errors:
- E1 = Success, message = "The operation completed successfully", code = 0
- E2 = Error, message = "The operation failed", code = 0x12345
When you call PutToLog(E1, "While reading the %d'th item", 7) it will log the string While reading the 7'th item err = 0x0
When you call PutToLog(E2, "While reading the %d'th item", 7) it will log the string error: While reading the 7'th item err = The operation failed (0x12345)
If we do what you suggest, then we are relying on the lldb::Error format provider, which does not have the ability to accept this kind of "contextual reason" string (i.e. the string "While reading the %d'th item" in the above example). So if we did this:
LLDB_LOG(log, error, "While reading the {0}'th item", 7)
Then the entire error must be formatted independently of the entire context string. So we could produce the output error: The operation failed (0x12345), context: While reading the 7'th item but this is slightly different from what was being printed before.
I didn't actually try this approach and see if anything broke, because Windows runs much fewer tests than the rest of LLDB, so even if my test suite passed, it wouldn't guarantee that another test somewhere else wasn't relying on the message being exactly as it currently prints.
I doubt anything is depending on the exact string printed to the log. We should just make the new output makes sense.
I'd format this message like this:
LLDB_LOG(log, "Reading the {0}'th item: {1}", 7, error)
which should give you something like:
Reading 7th item: Too many open files.
if you want, we can add the "error:" prefix, numeric error code, or something to the format provider,, but this would be enough for me.
This is also unnecessary.