Add coverage sensor 'Testwell CTC++' for textural reports #1486

rufinio · 2018-05-30T13:27:34Z

This change is

guwirth · 2018-05-31T05:45:58Z

@rufinio thx for providing this extension.

Could you provide some information please.

A link to the tool page.
How to call / use the tool to generate a report for the cxx plugin?
Wondering why you are parsing an ASCII report? Does the tool not provide XML?

Did not have the time to do a code review yet. Points should work:

Handle empty reports.
Support of https://github.com/SonarOpenCommunity/sonar-cxx/wiki/Supported-configuration-properties#sonarcxxerrorrecoveryenabled

Bertk

Very nice to add support for another commercial coverage tool 👍

Bertk · 2018-05-31T17:05:07Z

cxx-sensors/src/test/java/org/sonar/cxx/sensors/coverage/CxxTestwellCtcParserTest.java

+    sensor = new CxxCoverageSensor(new CxxCoverageCache(), language, context);
+    sensor.execute(context);
+
+    assertThat(context.lineHits("ProjectKey:HGBuildNumberLookup.cpp", 42)).isEqualTo(10);


Please use one assertThat statement per test. You can also use SoftAssertions (see http://joel-costigliola.github.io/assertj/core/api/org/assertj/core/api/SoftAssertions.html)

Bertk · 2018-05-31T17:05:25Z

cxx-sensors/src/test/java/org/sonar/cxx/sensors/coverage/CxxTestwellCtcParserTest.java

+    sensor = new CxxCoverageSensor(new CxxCoverageCache(), language, context);
+    sensor.execute(context);
+
+    assertThat(context.lineHits("ProjectKey:test-wildmatch.c", 3)).isEqualTo(209);


Please use one assertThat statement per test. You can also use SoftAssertions (see http://joel-costigliola.github.io/assertj/core/api/org/assertj/core/api/SoftAssertions.html)

Bertk · 2018-05-31T17:14:32Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcParser.java

+    }
+  }
+
+  private void addEachLine(CoverageMeasures coverageMeasures) {


Please reduce complexity of this method (e.g. extract methods). The Cognitive Complexity of this method is 57.

Can you recommend a tool for Cognitive Complexity?
Which value range is good?

Bertk · 2018-05-31T17:20:43Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcParser.java

+    if((new File(filename)).isAbsolute() == false) {
+      normalFilename = FilenameUtils.normalize("./" + filename);
+    }
+    else {


Style: Move this "else" on the same line that the previous closing curly brace (4 times in this file)

Please align with the current style.

…condition

…closing curly brace

rufinio · 2018-06-01T09:18:00Z

A link to the tool page.

https://www.verifysoft.com/en_ctcpp.html

How to call / use the tool to generate a report for the cxx plugin?

Adapted from Testwell CTC++ User's Guid (Basic Use of CTC++)
Suppose we have the following five source files that form a complete program: prime.c io.c calc.c. This program can be compiled and linked in many ways, one way being the following
cl –Feprime.exe prime.c io.c calc.c
which results in the prime.exe program.
Now, we wish to apply CTC++ on our program, that is, we want to measure the files prime.c, io.c and calc.c and find out how thoroughly they were exercised in our test runs. First we need to instrument the files we wish to measure. Assume we wish to measure multicondition coverage. This can be done as follows:
ctc -i m cl –Feprime.exe prime.c io.c calc.c
As a result we get the instrumented prime.exe program. Here 'ctc' is the CTC++ Preprocessor utility, which makes the instrumentation on the given C and C++ source files and drives compiling/linking of the new instrumented target. The '-i m' command-line options to ctc mean "instrument for multicondition".
when ctc instruments source files, it maintains descriptions what the files contain (what interesting code there is to ctc, on what lines, etc.). This file is called symbolfile, and when it is not specified (like here) it will be MON.sym in current directory.
All right, now prime.exe is the instrumented version of the program. Let's do one test run.
After this test run we notice that the file MON.dat has born in the current directory (same directory as the symbolfile MON.sym was created to). It is a datafile, containing the collected execution counters when the code in the instrumented files was executed.
Now we wish to see the results of our test, i.e. what parts of the program the above run has executed. We use the CTC++ Postprocessor utility as follows:
ctcpost MON.sym MON.dat -p profile.txt
What we are asking here is that ctcpost takes the symbolfile MON.sym and the datafile MON.dat as input and produces an Execution Profile Listing to the file profile.txt.
To get the results of our test to sonarqube we add the follwoing line to configuration file sonar-project.properties:
sonar.cxx.coverage.reportPath=profile.txt

Wondering why you are parsing an ASCII report? Does the tool not provide XML?

Testwell CTC++ also provides a XML output as well as JSON output. I mainly use TXT and therefore I know better about it than XML.

Handle empty reports.

Tested by Test shouldConsumeEmptyReport

Support of sonar.cxx.errorRecoveryEnabled

I wonder if that is applicable for this extension: In my optinion invalid file references or line numbers has to be handled by calling layer (CxxCoverageSensor).
In case of errors in a report file: This extension can't deside between tolerant and strict mode. No data and corrupt data have the same effect that regex doesn't match and no coverage data is collected.

…ons.

guwirth · 2018-06-02T08:30:31Z

@rufinio thx for your answer. Which version of the tool are you using / testing? What should we write in the docu? Supporting version x and later...

guwirth · 2018-06-02T08:32:08Z

@rufinio found also this page http://www.testwell.fi/ctcdesc.html. Is the tool from Testwell or Verisoft?

guwirth

Looks good. Only minor findings.

guwirth · 2018-06-02T08:27:00Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcParser.java

+   */
+  @Override
+  public void processReport(final SensorContext context, File report, final Map<String, CoverageMeasures> coverageData) {
+    LOG.debug("Parsing 'Testwell CTC++' format");


To make clear that ‚only‘ textual format is supported:
Parsing 'Testwell CTC++' textual format

guwirth · 2018-06-02T08:39:24Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/CxxCoverageSensor.java

@@ -67,6 +67,7 @@ public CxxCoverageSensor(CxxCoverageCache cache, CxxLanguage language, SensorCon
    parsers.add(new CoberturaParser());
    parsers.add(new BullseyeParser());
    parsers.add(new VisualStudioParser());
+    parsers.add(new TestwellCtcParser());


Maybe better TestwellCtcTxtParser?

ivangalkin · 2018-06-02T22:59:14Z

@rufinio Technical feedback: I am not sure, if your parser fits into the existing framework. Please see the CxxCoverageSensor::processReports(): it iterates over all registered CoverageParsers and gives each of them a chance to process the coverage report. If parser doesn't recognize the format it must either throw an exception XMLStreamException/EmptyReportException or produce an empty map Map<String, CoverageMeasures> (please see CxxCoverageSensor::parseCoverageReport()). Not sure about the map emptiness, but your parser never throws as far as I see. That's suspicious. Please consider using EmptyReportException as a signal, that the file format was not recognized.

@guwirth w.r.t. #1465 and the generic coverage format, wouldn't it be more foresighted to create an external (?) converter CTC++ -> XML and import the coverage by means of sonar.coverageReportPaths?

ivangalkin · 2018-06-02T23:45:52Z

one more side remark: TestwellCtcParser.java has common parts with https://github.com/Londran/sonar-ctc/blob/master/src/main/java/org/sonar/plugins/ctc/api/parser/CtcTextParser.java (among others some logging messages are 100% identical).

The original file is copyrighted

/*
 * Testwell CTC++ Plugin
 * Copyright (C) 2014 Verifysoft Technology GmbH
...
*/

Not sure if you can just skip the original copyright of LGPL3 code. Please double-check.

guwirth · 2018-06-03T20:27:03Z

Not sure if you can just skip the original copyright of LGPL3 code. Please double-check.

Source is LGPL and as long derivative work is again under license LGPL this should be no problem. But for later documentation it makes sense to add a comment below our header with a link to the original source.

rufinio · 2018-06-04T07:38:03Z

@guwirth:

Which version of the tool are you using / testing? What should we write in the docu? Supporting version x and later...

Testwell CTC++

Prerequisites

Testwell CTC++ Version 7.2 and later.

1. Generate instrumented executable

Suppose we have the following source files that form a complete program: prime.c io.c calc.c. This program can be compiled and linked in many ways, one way being the following
cl –Feprime.exe prime.c io.c calc.c
or
gcc -o prime prime.c io.c calc.c
which results in the prime.exe / prime program.
Now, we wish to apply CTC++ on our program, that is, we want to measure the files prime.c, io.c and calc.c and find out how thoroughly they were exercised in our test runs. First we need to instrument the files we wish to measure. Assume we wish to measure multicondition coverage. This can be done as follows:
ctc -i m cl –Feprime.exe prime.c io.c calc.c
or
ctc -i m gcc -o prime prime.c io.c calc.c
As a result we get the instrumented prime.exe program. Here 'ctc' is the CTC++ Preprocessor utility, which makes the instrumentation on the given C and C++ source files and drives compiling/linking of the new instrumented target. The '-i m' command-line options to ctc mean "instrument for multicondition".
when ctc instruments source files, it maintains descriptions what the files contain (what interesting code there is to ctc, on what lines, etc.). This file is called symbolfile, and when it is not specified (like here) it will be MON.sym in current directory.
All right, now prime.exe is the instrumented version of the program. Let's do one test run.

2. Generate coverage report

After this test run we notice that the file MON.dat has born in the current directory (same directory as the symbolfile MON.sym was created to). It is a datafile, containing the collected execution counters when the code in the instrumented files was executed.
Now we wish to see the results of our test, i.e. what parts of the program the above run has executed. We use the CTC++ Postprocessor utility as follows:
ctcpost MON.sym MON.dat -p profile.txt
What we are asking here is that ctcpost takes the symbolfile MON.sym and the datafile MON.dat as input and produces an Execution Profile Listing to the file profile.txt.

3. Read coverage file with SonarQube

To get the results of our test to sonarqube we add the following line to configuration file sonar-project.properties:
sonar.cxx.coverage.reportPath=profile.txt

Testwell or Verifysoft

Verifysoft Technology GmbH (Offenburg/Germany) has acquired all intellectual property rights for the software test and analysis tools of Testwell (Finland).
The aquisition includes Testwell CTC++, CMT++/CMTJava und CTA++ as well as tools for the ADA programming language.
Source: https://www.verifysoft.com/en_verifysoft_acquires_testwell_ipr.html

@ivangalkin:
If scanner can't recognize file format, it's signaled by an empty map Map<String, CoverageMeasures>. You can check this behavior by running test shouldConsumeEmptyReport.

…port can have TXT, XML or JSON format. This parser is aligned to TXT format.

…riginal source.

ivangalkin

some minor comments w.r.t. to the style etc

ivangalkin · 2018-06-07T22:08:05Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcTxtResult.java

+  FILE_COND("^\\Q***TER\\E +\\d+ % \\( *(\\d+)/ *(\\d+)\\) of FILE (?:.*)$"),
+  FILE_STMT("^ {6} +\\d+ % \\( *(\\d+)/ *(\\d+)\\) statement.*$");
+
+  public static final Pattern REPORT_HEADER = Pattern.compile(MON_SYM.patternString + "\\s+" + MON_DAT.patternString


here and below the joining can be simplified IMHO

String.join("\s+", MON_SYM.patternString, MON_DAT.patternString, LIS_DTE.patternString, COV_VIW.patternString);

ivangalkin · 2018-06-07T22:08:56Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcTxtResult.java

+  public static final Pattern REPORT_FOOTER = Pattern.compile(SRC_FLS.patternString + "\\s+" + HDR_EXT.patternString + "\\s+"
+    + FKT_EXT.patternString + "\\s*" + SRC_LNS.patternString, MULTILINE);
+  public static final Pattern FILE_HEADER = Pattern.compile(FILE_MONI.patternString + "\\s+" + FILE_INST.patternString, MULTILINE);
+  public static final Pattern SECTION_SEP = compile("^-{77}|={77}$", MULTILINE);


here and below: non-consistent compile() invocation: Pattern.compile() vs just compile()
I personally would prefer not to import like import static java.util.regex.Pattern.compile; but that's a matter of taste; the code just has to be consistent

ivangalkin · 2018-06-07T22:18:03Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcTxtParser.java

+  private static final Logger LOG = Loggers.get(TestwellCtcTxtParser.class);
+
+  private Scanner scanner;
+  private Matcher matcher;


keeping Matcher object as a state doesn't look correct to me. I believe it wold be easier to read and to understand if Matcher will be created in scope of each function. Especially because of permanent calls like matcher.reset() or matcher.usePattern()

Using matcher.reset() is better for performance at the cost of being less readable. In the case of a loop it is one less object to create in each loop iteration, and correspondingly one less object to be garbage collected per loop iteration.
After I moved matcher object in scope of each method I saw in my tests with report_big.txt about 5% decrease in performance. Hope that is compensated by the better readability.

ivangalkin · 2018-06-07T22:24:26Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcTxtParser.java

+
+  private Scanner scanner;
+  private Matcher matcher;
+  private State state;


same here: having a 'state' only makes the logic more complex IMHO

the main parsing loop is just something like that:

if ( parseReportHead() ) { while( parseUnit(coverageData) ) { } }

where each function returns true if parsing was successful

ivangalkin · 2018-06-07T22:43:47Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcTxtParser.java

+  private void parseFileUnit(final Map<String, CoverageMeasures> coverageData) {
+    LOG.debug("Parsing file section...");
+
+    String normalFilename;


here and below: there is no need to declare variable in advance, it's not C89

ivangalkin · 2018-06-07T22:48:28Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcTxtParser.java

+    int lineHitsFalse;
+    boolean conditionDetected;
+
+    lineIdPrev = 0;


same here and below: please combine declaration and initialization (although '0' and 'false' are actually set by default, but maybe it is more readable)

ivangalkin · 2018-06-07T22:50:41Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcTxtParser.java

+
+  private void addEachLine(CoverageMeasures coverageMeasures) {
+
+    int lineIdCur;


int lineIdCur = Integer.parseInt(matcher.group(LINE_NR_GROUP)); belong into the do-loop

please double-check the following variable declaration; the scope of some of them must be reduced;
only loop-invariants or some states (accumulators) should be declared here

ivangalkin · 2018-06-07T22:54:31Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcTxtParser.java

+        } else {
+          // multicondition
+
+          if (conditionDetected == true) {


if (conditionDetected) {

ivangalkin · 2018-06-07T22:56:20Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcTxtParser.java

+  }
+
+  private void setLinehits(CoverageMeasures coverageMeasures, int lineIdPrev, int lineIdCur, int lineHits) {
+    int lineIdNext;


please reduce the scope

if (lineIdPrev > 0) { int lineIdNext = lineIdPrev + 1; while (lineIdNext < lineIdCur) { ....

ivangalkin · 2018-06-07T23:03:35Z

cxx-sensors/src/test/java/org/sonar/cxx/sensors/coverage/CxxTestwellCtcTxtParserTest.java

+  private final MapSettings settings = new MapSettings();
+
+  @Before
+  public void setUp() {


It is very error-prone to share mutable state between test cases
maybe it's convenient (?) to declare ...

private CxxCoverageSensor sensor;

private DefaultFileSystem fs;

private SensorContextTester context;

... and permanently reset them in @Before...

but sharing of...

private final MapSettings settings = new MapSettings();

... is just wrong IMHO

private static MapSettings singletonMapSettings( String key, String value ) { MapSettings settings = new MapSettings(); settings.set( key, value ); return settings; } @Test public void myWhateverTest() { MapSettings settings = singletonMapSettings( "some key", "some value ); }

P. S. I grepped in other tests for settings and these pattern seems to be common (which still doesn't make it correct). Feel free to ignore my comment.

…in boolean expressions.

guwirth · 2018-06-10T06:44:33Z

P. S. I grepped in other tests for settings and these pattern seems to be common (which still doesn't make it correct). Feel free to ignore my comment.

@ivangalkin maybe we should fix this in an extra refactoring task for all unit tests?

guwirth · 2018-06-12T15:42:22Z

@rufinio do you have time to fix the review comments from @ivangalkin?

guwirth

Looks good, ready to merge.

ivangalkin

Thank you for applying of the review comments. The current ones are less important: The one with try-with-resources or the scope of Matcher headerMatcher could be still improved IMHO, but the remaining comments are about style. You decide. Great job BTW

ivangalkin · 2018-06-13T22:00:52Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcTxtParser.java

@@ -79,113 +71,88 @@ public TestwellCtcTxtParser() {
  @Override
  public void processReport(final SensorContext context, File report, final Map<String, CoverageMeasures> coverageData) {
    LOG.debug("Parsing 'Testwell CTC++' textual format");
-
+
    try {
      this.scanner = new Scanner(report).useDelimiter(SECTION_SEP);


I missed this during the previous comment: in order to avoid this.scanner.close() calls (e. g. in case of exception), one could use so called "try with resources".

try ( this.scanner = new Scanner(report).useDelimiter(SECTION_SEP) ) { ... } catch ( ... ) { }

Since Scanner is AutoCloseable it will be automatically closed when control flow lefts the try scope (see documentation)

ivangalkin · 2018-06-13T22:01:59Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcTxtParser.java

    } else {
-      state = State.END;
      scanner.close();


scanner.close() will be not necessary if try-with-resources will be used

ivangalkin · 2018-06-13T22:05:34Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcTxtParser.java

-    while (!matcher.reset(scanner.next()).usePattern(FILE_RESULT).find()) {
-      parseLineSection(coverageMeasures);
+    String nextLine = scanner.next();
+    while (!FILE_RESULT.matcher(nextLine).find()) {


looks like a classic use-case for a for loop to me:

for (String nextLine = scanner.next(); FILE_RESULT.matcher(nextLine).find(); nextLine = scanner.next()) { parseLineSection(coverageMeasures, nextLine); }

... but it's a matter of taste

ivangalkin · 2018-06-13T22:35:18Z

cxx-sensors/src/main/java/org/sonar/cxx/sensors/coverage/TestwellCtcTxtParser.java

-    filename = matcher.group(1);
-    if((new File(filename)).isAbsolute() == false) {
+    String filename = headerMatcher.group(1);
+    if (!(new File(filename)).isAbsolute()) {


parenthesis are not necessary if (!new File(filename).isAbsolute()) {

guwirth · 2018-06-14T07:05:00Z

@rufinio for me the code is ok. If you like to work-in the last points from @ivangalkin tell me.
Otherwise I would merge it now.

rufinio · 2018-06-14T07:07:54Z

Yes, I'd like to apply these last points.

… to for loop. Inverted if statement.

guwirth · 2018-06-14T16:18:02Z

@rufinio thanks a lot for your contribution!

rufinio added 2 commits May 30, 2018 13:22

Add coverage sensor 'Testwell CTC++'

dd38105

Add tests for coverage sensor 'Testwell CTC++'

5deff42

guwirth requested review from Bertk and guwirth May 31, 2018 05:34

guwirth assigned rufinio May 31, 2018

guwirth added the enhancement label May 31, 2018

guwirth added this to the 1.1 milestone May 31, 2018

Bertk suggested changes May 31, 2018

View reviewed changes

rufinio added 3 commits June 1, 2018 08:57

Testwell CTC++: Corrected line coverage in case of line follows multi…

837292b

…condition

Testwell CTC++: Style: Moved else on the same line that the previous …

51908cb

…closing curly brace

Testwell CTC++: Avoid endless loop if report has no footer.

46070cf

rufinio added 3 commits June 1, 2018 11:32

Testwell CTC++: one assertThat statement per test. Use of SoftAsserti…

bd15a84

…ons.

Testwell CTC++: delete unused import.

9f6de0a

Testwell CTC++: extract methods to reduce complexity.

01e02ff

guwirth requested changes Jun 2, 2018

View reviewed changes

guwirth changed the title ~~Add coverage sensor 'Testwell CTC++'~~ Add coverage sensor 'Testwell CTC++' for textural reports Jun 2, 2018

rufinio added 2 commits June 4, 2018 11:16

Testwell CTC++: TestwellCtcParser renamed to TestwellCtcTxtParser: Re…

8d7466d

…port can have TXT, XML or JSON format. This parser is aligned to TXT format.

Testwell CTC++: Added a comment below our header with a link to the o…

c2ed378

…riginal source.

guwirth approved these changes Jun 6, 2018

View reviewed changes

guwirth requested a review from ivangalkin June 6, 2018 15:23

ivangalkin suggested changes Jun 7, 2018

View reviewed changes

Testwell CTC++: joining string simplified. removed static imports.

77e4a78

rufinio added 3 commits June 8, 2018 13:51

Testwell CTC++: removed 'state' to reduce the complexity of logic.

178f52d

Testwell CTC++: reduced scope of variable declaration. use shortcuts …

ddc7893

…in boolean expressions.

Testwell CTC++: typo.

dd6b232

Bertk approved these changes Jun 9, 2018

View reviewed changes

Testwell CTC++: use shortcuts in boolean expressions.

75d6363

Testwell CTC++: Moved Matcher object in scope of each method.

6120a22

guwirth approved these changes Jun 13, 2018

View reviewed changes

ivangalkin approved these changes Jun 13, 2018

View reviewed changes

Testwell CTC++: Use try-with-resources functionality. Converted while…

b575a66

… to for loop. Inverted if statement.

guwirth merged commit b28b697 into SonarOpenCommunity:master Jun 14, 2018

guwirth mentioned this pull request Jun 20, 2018

V1.1 release notes draft #1502

Closed


		private void addEachLine(CoverageMeasures coverageMeasures) {

		int lineIdCur;

Add coverage sensor 'Testwell CTC++' for textural reports #1486

Add coverage sensor 'Testwell CTC++' for textural reports #1486

Conversation

rufinio commented May 30, 2018 • edited by SonarOpenCommunityAdmin Loading

guwirth commented May 31, 2018

Bertk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rufinio commented Jun 1, 2018

A link to the tool page.

How to call / use the tool to generate a report for the cxx plugin?

Wondering why you are parsing an ASCII report? Does the tool not provide XML?

Handle empty reports.

Support of sonar.cxx.errorRecoveryEnabled

guwirth commented Jun 2, 2018

guwirth commented Jun 2, 2018

guwirth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ivangalkin commented Jun 2, 2018

ivangalkin commented Jun 2, 2018

guwirth commented Jun 3, 2018

rufinio commented Jun 4, 2018

Testwell CTC++

Prerequisites

1. Generate instrumented executable

2. Generate coverage report

3. Read coverage file with SonarQube

ivangalkin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

guwirth commented Jun 10, 2018

guwirth commented Jun 12, 2018

guwirth left a comment

Choose a reason for hiding this comment

ivangalkin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

guwirth commented Jun 14, 2018

rufinio commented Jun 14, 2018

guwirth commented Jun 14, 2018

rufinio commented May 30, 2018 •

edited by SonarOpenCommunityAdmin

Loading