[cfe-dev] Writing a fix-it for errors already found by clang

Stuart Thomson via cfe-dev cfe-dev at lists.llvm.org
Fri Oct 5 03:50:34 PDT 2018

Hi Jonas,

Thanks for this.

  *   As far as I can tell clang does not emit a fix-it hint for this error. There is no hint on the command line and running clang-tidy with -fix-errors results in no change in the source.
  *   Dumping the AST shows the VarDecl in question but it is marked "invalid". Also when I try to write a matcher it doesn't seem to be able to find the initializer so I think you are right that the node has been removed.

I'm not sure how exactly I would go about adding this to the frontend - do you have any suggestions for how to begin?


From: Jonas Toth <development at jonas-toth.eu>
Sent: 05 October 2018 11:05
To: Stuart Thomson <Stuart.Thomson at eu.medical.canon>; cfe-dev at lists.llvm.org
Subject: Re: [cfe-dev] Writing a fix-it for errors already found by clang

Hi Stuart,

does clang itself emit a fix-it hint? As it does for some errors already, you could try to add this to the clang frontend itself instead of a separate clang-tidy check.
clang-tidy checks don't have information of other diagnostics from Sema or other checks, each check is independent in that sense. They use the AST as information.
When there are errors in the original source-code, the corresponding AST-Nodes could be removed to recover from these errors. This makes it complicated to write
a reliable clang-tidy check (if not impossible).

Does 'clang-check -ast-dump file.cpp' contain the offending nodes?

Best Jonas
(forgot to include cfe-dev)
Am 05.10.2018 um 11:56 schrieb Stuart Thomson via cfe-dev:

I want to write a clang-tidy check which would fix something which clang currently considers an error (namely initializing BSTR with const wchar_t *). I am trying to write node matchers etc. but it seems like it might be redundant given that clang already know when this is happening. I wonder if there is some way to grab the diagnostic messages and if the message matches a given message (with a regex or something) clang could attempt to fix the offending code?

Also, is this complicated by the fact that this diagnostic is and error and not just a warning?



cfe-dev mailing list

cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181005/6f27030c/attachment.html>

More information about the cfe-dev mailing list