[PATCH] D83419: [clangd] Add error() function for creating formatv-style llvm::Errors. NFC
Haojian Wu via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Jul 8 23:51:34 PDT 2020
hokein added a comment.
In D83419#2140573 <https://reviews.llvm.org/D83419#2140573>, @sammccall wrote:
> In D83419#2140311 <https://reviews.llvm.org/D83419#2140311>, @njames93 wrote:
>
> > I'm not a huge fan of using `error`, maybe `createError`,
> > Its definitely out of place in Logger, but there is no where else better for it to live short of a new file which seems overkill.
>
>
> Yeah, the naming is definitely the hardest part to be sure of here.
> It's an extremely commonly used function: 75 references to StringError + another 20 or so references to local helpers.
> This puts it in the same class as log (95), vlog (50), elog(85).
> It's also similar in that it is cross cutting and has the same format string + args shape (so wrapping affects it similarly).
while the name `error` aligns well with `elog/vlog`, I'm not in favor of it. I think the key point is that `error` creates an **`Error`** object, and this object must be checked before destructing. `error` name makes it look like a print function, I'd prefer to add a verb to the name, e.g. `makeError`
>> its used in many other parts of llvm, typically with static linkage.
>
> Yeah, there's some precedent, though not overwhelming consensus. Outside clangd I count 10 `createError`s, 7 `make_string_error`s, 4 `error`s, 1 `makeError`, 1 `makeStringError`, and the canonical `makeStringError` and `make_error`.
>
> But I think this is just a place where wider LLVM is making different tradeoffs:
>
> - for good reasons: many errors are diagnostics or don't need to be carefully routed back to a specific request
> - for bad reasons: e.g. compliance with the "verb phrase" policy that's poorly observed and itself seems like a sad accident of history: http://lists.llvm.org/pipermail/llvm-dev/2018-May/thread.html#123547
> - llvm::Error itself seems like a pretty strong argument that existing practice doesn't guarantee good ergonomics
it would be nicer if we could offer this across llvm-projects, but agree that logger.cc seems to be the best place to place it so far.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D83419/new/
https://reviews.llvm.org/D83419
More information about the cfe-commits
mailing list