Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an option to include all analysis #6

Open
olsh opened this issue Jul 11, 2019 · 2 comments
Open

Add an option to include all analysis #6

olsh opened this issue Jul 11, 2019 · 2 comments
Labels
enhancement New feature or request

Comments

@olsh
Copy link
Contributor

olsh commented Jul 11, 2019

At the moment all the imported rules are filtered by this predicate

protected @Nullable Collection<Predicate<InspectCodeIssueDefinitionModel>> getIssueDefinitionFilterPredicates() {
return Arrays.asList(
ObjectPredicates.isNotNullPredicate(),
InspectCodePredicates.hasValidIssueSeverity(),
InspectCodePredicates.hasNonEmptyIssueDescription(),
InspectCodePredicates.isCSharpIssueDefinition(),
InspectCodePredicates.isVisualBasicIssueDefinition().negate(),
InspectCodePredicates.isWebRelatedCategory().negate());

It'd be nice to have an option to disable this filter (except hasValidIssueSeverity and hasNonEmptyIssueDescription) or add two options, something like Rule ID regex and Category ID regex which will control this

inspectCodeIssueDefinitionModel.getCategory() != null
&& ("JsStrictModeErrors".equalsIgnoreCase(inspectCodeIssueDefinitionModel.getCategoryId())
|| "JsStrictModeErrors".equalsIgnoreCase(inspectCodeIssueDefinitionModel.getCategory()));
and this
Pattern.compile("^\\s*(?!AngularHtml\\.|Asp\\.|Cpp|Css|Es\\dFeature|Html\\.|VB|Web\\.|WebConfig\\.)\\S{3,}", Pattern.CASE_INSENSITIVE);
filter.

This may sound pretty insane, but the R# tools have more analytics than the SQ analyzers, plus R# is more robust at .csthml and .asp(x) parsing.

@steffen-wilke steffen-wilke added the enhancement New feature or request label Jul 12, 2019
@BrightLight
Copy link
Member

Just to add some background: I understand you'd like to analyze .cshtml and .asp(x) files, which InspectCode can certainly do. However, this plugin currently registers with SonarQube only for .cs files (at least that's my understanding).
Ideally, this plugin basically needs to have a list of available rules per language. But InspectCode only outputs one big XML file (inspectcode_issue_definitions.xml) with all its "issue types", but I don't see an obvious way to figure out which issue type is valid for which language(s). Sure, some are obvious, like Asp.ResolveWarning very likely belongs to .asp(x), CommonJsExternalModule is probably a JavaScript inspection, VBWarnings::BC400005 is obviously a Visual Basic inspection.
But others are not so clear. For instance, RedundantEmptyCaseElse can probably happen in both C# and VB (and maybe even other languages?). Which means when we generate the plugin it is hard to assign the right rules for each language.
Ideally you see in SonarQube for any given language only rules that actually make sense for that language. We just don't know how to get there yet.

@olsh
Copy link
Contributor Author

olsh commented Aug 23, 2019

Hi @BrightLight ,

However, this plugin currently registers with SonarQube only for .cs files (at least that's my understanding).

I didn't check the registration and import source code, but the plugin imports issues for cshtml, ts, js, css, aspx and other files. I did the changes I mentioned above, and it just works.

steffen-wilke added a commit that referenced this issue Jun 10, 2020
These are just disabled by default and depending on the project/company policy they should be enabled or not. Previously these types of rules were not imported at all, making them unavailable for tracking in SonarQube.
This was noticeable due to the fact that we now export the ReSharper rules via InspectCode with --no-buildin-settings to make them even with the ReSharper default. Some rules (e.g. TabsAreDisallowed) changed in that process to "DO_NOT_SHOW" which made them disappear after an update to this plugin >= 1.0.0.202013.

With this change we now support/provide C# rules with "DO_NOT_SHOW" severity because this is just a pre-set that the individual use could change and otherwise these rules would not even be available.

Issue #6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants