Skip to content

go-xman/slang

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

SLang

Build Status Quality Gate Coverage

This is a developer documentation. If you want to analyze source code in SonarQube read one of the following documentations:

SLang (SonarSource Language) is a framework to quickly develop code analyzers for SonarQube. SLang defines language agnostic AST. Using this AST we can develop simple syntax based rules. Then we use parser for real language to create this AST. Currently Ruby and Scala analyzers use this approach.

Ruby

We use whitequark parser to parse Ruby language by embedding it using JRuby runtime.

  • AST documentation for the parser can be found here
  • We use simple Ruby script to call the parser and invoke our visitor written in Java

Scala

We use Scalameta to parse Scala language.

Scala coverage

For Scala files, we will import both Scoverage and JaCoCo coverage reports. Note that this will result in strange behavior since:

  • Only line coverage will be used from the Scoverage report.
  • JaCoCo can be imprecise when computing conditions coverage on Scala code, generating FP (typically on pattern matching).

This situation only applies to two Scala files, this current situation is acceptable.

Go

We use the native Go parser to parse Go language.

Have question or feedback?

To provide feedback (request a feature, report a bug etc.) use the SonarQube Community Forum. Please do not forget to specify the language, plugin version and SonarQube version.

Building

Setup

If you are on Windows, read the sonar-go-to-slang/README.md instructions.

SonarSource internal usage: Configure your gradle.properties - read the private/README.md instructions.

Build

Build and run Unit Tests:

./gradlew build

Integration Tests

By default, Integration Tests (ITs) are skipped during build. If you want to run them, you need first to retrieve the related projects which are used as input:

git submodule update --init its/sources

Then build and run the Integration Tests using the its property:

./gradlew build -Pits --info --no-daemon -Dsonar.runtimeVersion=7.9

You can also build and run only Ruling Tests using the ruling property:

./gradlew build -Pruling --info --no-daemon -Dsonar.runtimeVersion=7.9

If you want to run ruling tests for specific language, you can use ruling-{lang} property (ruling-scala, ruling-ruby, ruling-go). For example:

./gradlew build -Pruling-scala --info --no-daemon -Dsonar.runtimeVersion=7.9

License headers

Note: The license check is not working correctly, see SONARSLANG-367.

When adding a new source file, you will need to add license headers. Instead of copy-pasting blocks, the following command line can be used:

./gradlew licenseFormat

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Java 85.2%
  • Go 6.0%
  • HTML 4.5%
  • Scala 3.1%
  • Ruby 0.7%
  • ANTLR 0.4%
  • Other 0.1%