Writing a fix-it for errors already found by clang

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Writing a fix-it for errors already found by clang

via cfe-dev

Hi,

 

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?

 

Thanks,

Stuart

 

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Writing a fix-it for errors already found by clang

via cfe-dev
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:

Hi,

 

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?

 

Thanks,

Stuart

 

 



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Writing a fix-it for errors already found by clang

via cfe-dev

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?

 

Cheers,

Stuart

 

 

From: Jonas Toth <[hidden email]>
Sent: 05 October 2018 11:05
To: Stuart Thomson <[hidden email]>; [hidden email]
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:

Hi,

 

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?

 

Thanks,

Stuart

 

 




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Writing a fix-it for errors already found by clang

via cfe-dev

Hi Stuart,

I am not too active in the frontend, but in `lib/Parse/*` is the code for parsing and it does emit FixitHints. You can grep around with

`git grep "FixItHint::CreateInsertion"`

Documentation for FixIt: https://clang.llvm.org/doxygen/classclang_1_1FixItHint.html

Documentation for CFE Internals: https://clang.llvm.org/docs/InternalsManual.html#fix-it-hints

Someone else might give you more specific advice, but reading the code and some doc might give you a good start :)

Best Jonas


Am 05.10.2018 um 12:50 schrieb Stuart Thomson:

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?

 

Cheers,

Stuart

 

 

From: Jonas Toth [hidden email]
Sent: 05 October 2018 11:05
To: Stuart Thomson [hidden email]; [hidden email]
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:

Hi,

 

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?

 

Thanks,

Stuart

 

 




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev