JarCastingSLang
This is a developer documentation. If you want to analyze source code in SonarQube read one of the following documentations:
- Kotlin language: analysis of Kotlin documentation
- Ruby language: analysis of Ruby documentation
- Scala language: analysis of Scala documentation
- Go language: analysis of Go documentation
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 Kotlin, Ruby and Scala analyzers use this approach.
Kotlin
We use embeddable library of Kotlin compiler to create AST and visitor to create SLang AST.
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-kotlin, ruling-scala, ruling-ruby, ruling-go). For example:
./gradlew build -Pruling-kotlin --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
