[analyzer] Tighter command line interface, new API to register dependencies

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

[analyzer] Tighter command line interface, new API to register dependencies

David Blaikie via cfe-dev
Hi all!

This mail is a heads up for out-of-tree checker developers that I'm planning to land a variety of changes to how checker registration works. Also, I already commited some changes to make the command line interface a little less annoying. While I will properly document most of these in some form or another with a file in the actual repo, I'll leave about a week for everyone to raise objections.

===--- Checker registration ---===

Registering more than one checker in a registry function leads to multiple checkers receiving the same name. The solution was to reimplement parts on the checker registration process.

1. From now, all checkers should have a corresponding shouldRegister##CHECKERNAME function defined, similar to register##CHECKERNAME. The intent here is that once a registry function is called, it should register the checker. If based on some language options you chose not to register your checker within register##CHECKERNAME, please move all such conditions to the new function.

2. A registry function is no longer allowed to register more then one checker. Also, CheckerManager::registerChecker<CHECKER> may only be called once per checker. If you intend to acquire a checker object within a registry function (for example, if it merely enables extension to the main checker), please use CheckerManager::getChecker<CHECKER>. You can ensure that the checker you'd like to acquire is already registered by adding it as a dependency via CheckerRegistry::addDependency.

3. CheckerRegistry was moved from the Core directory to Frontend.

===--- Command line interface ---===

Mainly focusing on -analyzer-config options, it was an ancient and annoying issue that any invalid input would be ignored and the analyzer simply didn't do what you want -- this is changing. Please note that most of these have already landed.

1. AnalyzerOptions no longer supports adding non-checker options without modifying the actual implementation, which can be done by writing a new entry in AnalyzerOptions.def.

2. There is a new -analyzer-config-help flag to list all non-checker configurations.

3. A new flag was added that will emit a warning on almost any invalid -analyzer-config input, called -analyzer-config-compatibility-mode. When the analyzer is invoked with -analyze (in driver mode, I'm unsure about the correct terminology), it will be set to false by default, but will be enabled with -cc1 (in frontend mode). You may enable this feature in the driver mode via -Xclang analyzer-config-compatibility-mode=true.

4. Similar plans are already in motion to make checker options similarly strict.

Cheers,
Kristóf Umann

_______________________________________________
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: [analyzer] Tighter command line interface, new API to register dependencies

David Blaikie via cfe-dev


On 12/10/18 8:57 AM, Kristóf Umann via cfe-dev wrote:
Hi all!

This mail is a heads up for out-of-tree checker developers that I'm planning to land a variety of changes to how checker registration works. Also, I already commited some changes to make the command line interface a little less annoying. While I will properly document most of these in some form or another with a file in the actual repo, I'll leave about a week for everyone to raise objections.

===--- Checker registration ---===

Registering more than one checker in a registry function leads to multiple checkers receiving the same name. The solution was to reimplement parts on the checker registration process.

1. From now, all checkers should have a corresponding shouldRegister##CHECKERNAME function defined, similar to register##CHECKERNAME. The intent here is that once a registry function is called, it should register the checker. If based on some language options you chose not to register your checker within register##CHECKERNAME, please move all such conditions to the new function.

2. A registry function is no longer allowed to register more then one checker. Also, CheckerManager::registerChecker<CHECKER> may only be called once per checker. If you intend to acquire a checker object within a registry function (for example, if it merely enables extension to the main checker), please use CheckerManager::getChecker<CHECKER>. You can ensure that the checker you'd like to acquire is already registered by adding it as a dependency via CheckerRegistry::addDependency.

Aren't we doing dependencies via Checkers.td?



3. CheckerRegistry was moved from the Core directory to Frontend.

===--- Command line interface ---===

Mainly focusing on -analyzer-config options, it was an ancient and annoying issue that any invalid input would be ignored and the analyzer simply didn't do what you want -- this is changing. Please note that most of these have already landed.

1. AnalyzerOptions no longer supports adding non-checker options without modifying the actual implementation, which can be done by writing a new entry in AnalyzerOptions.def.

2. There is a new -analyzer-config-help flag to list all non-checker configurations.

3. A new flag was added that will emit a warning on almost any invalid -analyzer-config input, called -analyzer-config-compatibility-mode. When the analyzer is invoked with -analyze (in driver mode, I'm unsure about the correct terminology), it will be set to false by default, but will be enabled with -cc1 (in frontend mode). You may enable this feature in the driver mode via -Xclang analyzer-config-compatibility-mode=true.

4. Similar plans are already in motion to make checker options similarly strict.

Cheers,
Kristóf Umann

_______________________________________________
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: [analyzer] Tighter command line interface, new API to register dependencies

David Blaikie via cfe-dev


On Mon, 10 Dec 2018, 21:58 Artem Dergachev <[hidden email] wrote:


On 12/10/18 8:57 AM, Kristóf Umann via cfe-dev wrote:
Hi all!

This mail is a heads up for out-of-tree checker developers that I'm planning to land a variety of changes to how checker registration works. Also, I already commited some changes to make the command line interface a little less annoying. While I will properly document most of these in some form or another with a file in the actual repo, I'll leave about a week for everyone to raise objections.

===--- Checker registration ---===

Registering more than one checker in a registry function leads to multiple checkers receiving the same name. The solution was to reimplement parts on the checker registration process.

1. From now, all checkers should have a corresponding shouldRegister##CHECKERNAME function defined, similar to register##CHECKERNAME. The intent here is that once a registry function is called, it should register the checker. If based on some language options you chose not to register your checker within register##CHECKERNAME, please move all such conditions to the new function.

2. A registry function is no longer allowed to register more then one checker. Also, CheckerManager::registerChecker<CHECKER> may only be called once per checker. If you intend to acquire a checker object within a registry function (for example, if it merely enables extension to the main checker), please use CheckerManager::getChecker<CHECKER>. You can ensure that the checker you'd like to acquire is already registered by adding it as a dependency via CheckerRegistry::addDependency.

Aren't we doing dependencies via Checkers.td?
I should've been more clear: in the official repo yes, and I guess using the same method out-of-tree is the easiest solution, but essentially this is what happening under the hood.


3. CheckerRegistry was moved from the Core directory to Frontend.

===--- Command line interface ---===

Mainly focusing on -analyzer-config options, it was an ancient and annoying issue that any invalid input would be ignored and the analyzer simply didn't do what you want -- this is changing. Please note that most of these have already landed.

1. AnalyzerOptions no longer supports adding non-checker options without modifying the actual implementation, which can be done by writing a new entry in AnalyzerOptions.def.

2. There is a new -analyzer-config-help flag to list all non-checker configurations.

3. A new flag was added that will emit a warning on almost any invalid -analyzer-config input, called -analyzer-config-compatibility-mode. When the analyzer is invoked with -analyze (in driver mode, I'm unsure about the correct terminology), it will be set to false by default, but will be enabled with -cc1 (in frontend mode). You may enable this feature in the driver mode via -Xclang analyzer-config-compatibility-mode=true.

4. Similar plans are already in motion to make checker options similarly strict.

Cheers,
Kristóf Umann

_______________________________________________
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: [analyzer] Tighter command line interface, new API to register dependencies

David Blaikie via cfe-dev
Sorry for the spam, hit send too early :/ when loading an external plugin, you can register your checkers with the supplied CheckerRegistry object, and my target audience was developers of external plugins, for example, us in Ericsson.

I guess for developers working here on the official repo, visiting the phabricator links or waiting for me to get together that documentation would be the best course of action :)

On Mon, 10 Dec 2018, 22:00 Kristóf Umann <[hidden email] wrote:


On Mon, 10 Dec 2018, 21:58 Artem Dergachev <[hidden email] wrote:


On 12/10/18 8:57 AM, Kristóf Umann via cfe-dev wrote:
Hi all!

This mail is a heads up for out-of-tree checker developers that I'm planning to land a variety of changes to how checker registration works. Also, I already commited some changes to make the command line interface a little less annoying. While I will properly document most of these in some form or another with a file in the actual repo, I'll leave about a week for everyone to raise objections.

===--- Checker registration ---===

Registering more than one checker in a registry function leads to multiple checkers receiving the same name. The solution was to reimplement parts on the checker registration process.

1. From now, all checkers should have a corresponding shouldRegister##CHECKERNAME function defined, similar to register##CHECKERNAME. The intent here is that once a registry function is called, it should register the checker. If based on some language options you chose not to register your checker within register##CHECKERNAME, please move all such conditions to the new function.

2. A registry function is no longer allowed to register more then one checker. Also, CheckerManager::registerChecker<CHECKER> may only be called once per checker. If you intend to acquire a checker object within a registry function (for example, if it merely enables extension to the main checker), please use CheckerManager::getChecker<CHECKER>. You can ensure that the checker you'd like to acquire is already registered by adding it as a dependency via CheckerRegistry::addDependency.

Aren't we doing dependencies via Checkers.td?
I should've been more clear: in the official repo yes, and I guess using the same method out-of-tree is the easiest solution, but essentially this is what happening under the hood.


3. CheckerRegistry was moved from the Core directory to Frontend.

===--- Command line interface ---===

Mainly focusing on -analyzer-config options, it was an ancient and annoying issue that any invalid input would be ignored and the analyzer simply didn't do what you want -- this is changing. Please note that most of these have already landed.

1. AnalyzerOptions no longer supports adding non-checker options without modifying the actual implementation, which can be done by writing a new entry in AnalyzerOptions.def.

2. There is a new -analyzer-config-help flag to list all non-checker configurations.

3. A new flag was added that will emit a warning on almost any invalid -analyzer-config input, called -analyzer-config-compatibility-mode. When the analyzer is invoked with -analyze (in driver mode, I'm unsure about the correct terminology), it will be set to false by default, but will be enabled with -cc1 (in frontend mode). You may enable this feature in the driver mode via -Xclang analyzer-config-compatibility-mode=true.

4. Similar plans are already in motion to make checker options similarly strict.

Cheers,
Kristóf Umann

_______________________________________________
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: [analyzer] Tighter command line interface, new API to register dependencies

David Blaikie via cfe-dev
I sadly won't be able to dedicate enough time to overcome some hurdles that stop me from commiting these things before the creation of the 8.0 branch, so it'll only land in the next major release.

Kristóf Umann <[hidden email]> ezt írta (időpont: 2018. dec. 10., H, 22:08):
Sorry for the spam, hit send too early :/ when loading an external plugin, you can register your checkers with the supplied CheckerRegistry object, and my target audience was developers of external plugins, for example, us in Ericsson.

I guess for developers working here on the official repo, visiting the phabricator links or waiting for me to get together that documentation would be the best course of action :)

On Mon, 10 Dec 2018, 22:00 Kristóf Umann <[hidden email] wrote:


On Mon, 10 Dec 2018, 21:58 Artem Dergachev <[hidden email] wrote:


On 12/10/18 8:57 AM, Kristóf Umann via cfe-dev wrote:
Hi all!

This mail is a heads up for out-of-tree checker developers that I'm planning to land a variety of changes to how checker registration works. Also, I already commited some changes to make the command line interface a little less annoying. While I will properly document most of these in some form or another with a file in the actual repo, I'll leave about a week for everyone to raise objections.

===--- Checker registration ---===

Registering more than one checker in a registry function leads to multiple checkers receiving the same name. The solution was to reimplement parts on the checker registration process.

1. From now, all checkers should have a corresponding shouldRegister##CHECKERNAME function defined, similar to register##CHECKERNAME. The intent here is that once a registry function is called, it should register the checker. If based on some language options you chose not to register your checker within register##CHECKERNAME, please move all such conditions to the new function.

2. A registry function is no longer allowed to register more then one checker. Also, CheckerManager::registerChecker<CHECKER> may only be called once per checker. If you intend to acquire a checker object within a registry function (for example, if it merely enables extension to the main checker), please use CheckerManager::getChecker<CHECKER>. You can ensure that the checker you'd like to acquire is already registered by adding it as a dependency via CheckerRegistry::addDependency.

Aren't we doing dependencies via Checkers.td?
I should've been more clear: in the official repo yes, and I guess using the same method out-of-tree is the easiest solution, but essentially this is what happening under the hood.


3. CheckerRegistry was moved from the Core directory to Frontend.

===--- Command line interface ---===

Mainly focusing on -analyzer-config options, it was an ancient and annoying issue that any invalid input would be ignored and the analyzer simply didn't do what you want -- this is changing. Please note that most of these have already landed.

1. AnalyzerOptions no longer supports adding non-checker options without modifying the actual implementation, which can be done by writing a new entry in AnalyzerOptions.def.

2. There is a new -analyzer-config-help flag to list all non-checker configurations.

3. A new flag was added that will emit a warning on almost any invalid -analyzer-config input, called -analyzer-config-compatibility-mode. When the analyzer is invoked with -analyze (in driver mode, I'm unsure about the correct terminology), it will be set to false by default, but will be enabled with -cc1 (in frontend mode). You may enable this feature in the driver mode via -Xclang analyzer-config-compatibility-mode=true.

4. Similar plans are already in motion to make checker options similarly strict.

Cheers,
Kristóf Umann

_______________________________________________
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