I'm looking for a way to trigger a static analyzer warning on specific code path that would normally not happen or indicate an unhandled error condition.
For example, I would like do write something like this:
int err = some_internal_call(arg1, arg2);
if (err == errInternalError) {
analyzer_assert();
}
Then when I run the analyzer, and it analyze all the different code path, it would warn me that the analyzer_assert() has been called.
Specifically looking into the clang analyzer, but I'm also curious if other analyzer have this feature.
It looks like I could add this feature to clang by write a custom checker, but I'd rather not have to do it myself.
Many analyzers have diagnostics, warning that conditions are always false or true. To find such situations you can use many different tools. But apparently you need another thing. You want to find always true/false conditions because of which a function with a certain name is always/never called, don't you?
If yes, most likely, there is no a ready-made solution. You need to either implement such functional yourself using Clang or you can reach out to someone who can do such a custom service for you. For example, our team implements similar customer-specific rules in a PVS-Studio analyzer. Such diagnostics are included in a separate group and are disabled by default. However, you can always enable and start using such diagnostics.
Related
I'm creating code for interfaces specified in IBM Rational Rhapsody. Rhapsody implicitly generates include statements for other data types used in my interfaces. But I would like to have more control over the include statements, so I specify them explicitly as text elements in the source artifacts of the component. Therefore I would like to prevent Rhapsody from generating the include statements itself. Is this possible?
If this can be done, it is mostly likely with Properties. In the feature box click on properties and filter by 'include' to see some likely candidates. Not all of the properties have descriptions of what exactly they do so good luck.
EDIT:
I spent some time looking through the properties as well an could not find any to get what you want. It seems likely you cannot do this with the basic version of Rhapsody. IBM does license an add-on to customize the code generation, called Rules Composer (I think); this would almost certainly allow you to customize the includes but at quite a cost.
There are two other possible approaches. Depending on how you are customizing the include statements you may be able to write a simple shell script, perhaps using sed, and then just run that script to update your code every time Rhapsody generates it.
The other approach would be to use the Rhapsody API to create a plugin/tool that iterates through all the interfaces and changes the source artifacts accordingly. I have not tried this method myself but I know my coworkers have used the API to do similar things.
Finally I found the properties that let Rhapsody produce the required output: GenerateImplicitDependencies for several elements and GenerateDeclarationDependency for Type elements. Disabling these will avoid the generation of implicit include statements.
What is currently the best way to write SonarQube 4.5 checks for :
Bytecode Analysis
Source Analysis
Unfortunately, I could not find an up-to-date web page providing a clear explanation, and I see that existing checks use many deprecated classes and methods, use "bridges" about to be abandonned, checks are regularly removed from the codebase (such as the XPath rule).
I would like to be sure that the checks I'm about to write will be well written and durable.
So...
should I use BytecodeVisitor to analyse bytecode ?
should I use BaseTreeVisitor to analyse sourcecode ?
What is the replacement for org.sonar.api.rules.RuleRepository ?
What is the replacement for org.sonar.api.resources.Java ?
What is the replacement for org.sonar.api.rules.AnnotationRuleParser ?
How can I write XPath like rules (BaseTreeVisitor is using SSLR and if I'm not wrong SonarQube is moving away from SSLR / AbstractXPathCheck is part of sslr squid bridge.)
What else should I know ?
In other words I'm a bit lost.
Thank you in advance for your help.
First thanks for your feedback,
There are in fact many questions in your question (sic) :
The way to write custom checks for Java as of today is to use the BaseTreeVisitor. All the other ways are now deprecated and we are working to be able to remove them (but it is not always straightforward as some of them requires a complete semantic analysis to be removed). What is currently lacking from this api is the access to the semantic analysis to be able to request type information read from bytecode.
You can have a look at this project : https://github.com/SonarSource/sonar-examples/tree/master/plugins/java-custom-rules
For all the other questions, please ask them on the mailing list.
(Small notes though : BaseTreeVisitor does not use SSLR directly, the java plugin is not moving away from SSLR rather from one class, specifically ASTNode, in order to work on a SyntaxTree with a class specific for each type of node, The drop of Xpath checks occurs in that logic of moving away from a non-typed SyntaxTree).
I want to create an extension to recognize specific comments in my code. I will use this to signal code smells by using the //# comment prefix. One feature of this extension will be to generate warnings for each comment encountered while compiling the code. Is it possible to do this?
I don't think you can hook into the compiler to generate warning. However, the "Error List" view aggregates errors, warnings and messages from multiple sources. Would it be good enough for you to simply append to that list?
Here's a link I could find on the subject : http://www.mztools.com/articles/2008/MZ2008022.aspx
There is a sample called CodeSweep that detects certain strings in comments (it is written to look for mild swear words) that adds tasks to your Task List. http://code.msdn.microsoft.com/Code-Sweep-3bfb7bb5 Reading this code could help you write your own extension if you can't use it as-is.
You could also use the existing task functionality and add your own keywords (like the out-of-the-box //HACK and //TODO - you could add //SMELL) which is quicker but gives you less control. http://msdn.microsoft.com/en-us/library/zce12xx2(v=VS.100).aspx. This may be all you need.
...any change?
The scenario is this:
For our company we develop a standard how code should look.
This will be the MS full rule set as it looks now.
For some specific projects we may want to turn off specific rules. Simply because for a specific project this is a "known exception". Example? CA1026 - while perfectly ok in most cases, there are 1-2 specific libraries we dont want to change those.
We also want to avoid having a custom rule set. OTOH putting in a suppress attribute on every occurance gets pretty convoluted pretty fast.
Any way to turn off a code analysis warning for a complete assembly without a custom rule set? We rather have that in a specific file (GlobalSuppressions.cs) than in a rule set for maintenance reasons, and to be more explicit ;)
There is no way to create an assembly-level exclusion that will cover all violations of that rule for types and/or members within the assembly.
You could probably still use the CodeAnalysisRules element in your project file, but this is essentially just as much work as a custom ruleset, and more difficult to track given that it's not shown in the project properties UI.
Regardless of the mechanism you would prefer to use, you should also consider whether you want to simply exclude existing violation or whether you want new violations to be introduced. If the former, you should add SuppressMessage attributes for the existing violations. If the latter, you should disable the rule for the assembly.
BTW, in case you weren't aware of this, you can suppress multiple violations at once in the violation list in VStudio.
You'd actually have more flexibility of exclusions with CodeIt.Right for static analysis. And saved all that time :)
I'm looking into writing an addin (or package, if necessary) for Visual Studio 2005 that needs watch window type functionality -- evaluation of expressions and examination of the types. The automation facilities provide
Debugger::GetExpression, which is useful enough, but the information
provided is a bit crude.
From looking through the docs, it sounds like an
IDebugExpressionContext2 would be more useful. With one of these it
looks as if I can get more information from an expression -- detailed
information about the type and any members and so on and so forth, without having everything come through as strings.
I can't find any way of actually getting a IDebugExpressionContext2,
though! IDebugProgramProvider2 sort of looks relevant, in that I
could start with IDebugProgramProvider2::GetProviderProcessData and
then slowly drill down until reaching something that can supply my
expression context -- but I'll need to supply a port to this, and it's
not clear how to retrieve the port corresponding to the current debug
session. (Even if I tried every port, it's not obvious how to tell
which port is the right one...)
I'm becoming suspicious that this simply isn't a supported use case, but with any luck I've simply missed something crashingly obvious.
Can anybody help?
By using IDebugExpressionContext you'll ultamitely end up getting ahold of an instance of IDebugProperty. This interface is implemented by the Expression Evaluator service. This is, typically, a language specific service. It's designed to abstract out the language specific details of evaluating an expression. It understands much higher level commands like "Evaluate", and inspection.
I don't think you're going to get what you're looking for though because you can't get ahold of any kind of type object this way. Nearly all of the inspection methods return their results in String form. For example you won't get the type Int32 but instead the string "int". This makes type inspection next to impossible.
I don't believe what you're trying is a supported case. The type system being evaluated doesn't exist in the current process. It exists in the debuggee process and is fairly difficult to get access to.
There's a hack you could do to get more information about the type of a variable you've evaluated using Debugger::GetExpression method.
You could evaluate "AppDomain.CurrentDomain.GetAssemblies()" to get all the assemblies loaded into the debugee, and cache them in your add-in. You may also need to listen for new assemblies being loaded onto the AppDomain.
Then, run the following:
Expression myExpression = Debugger.GetExpression(...);
Expression typeRefExpression = Debugger.GetExpression("typeof(" + myExpression.Type + ").FullName"
once you have the TypeFullName, you can search inside your assemblies cache for a matching System.Type, and once you have that, you can dig into it all you want using the standart Reflection API.
Note that this will only work in C#, because of its "typeof" keyword. You'll have to use a different keyword for VB.Net, for example.