Using the following versions
SonarQube Enterprise Edition v9.9.6 (build 92038)
sonar-scanner v6.1.0.4477 installed on MacOS build agents
swift-driver version: 1.87.3 Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5)
Target: arm64-apple-macosx14.0
We have an iOS app, which we build using Jenkins with in house MacOS build agents running sonar-scanner. We are using slather to convert coverage from xcode format and XCCompilationDB for generating compile_commands.json
Error thrown in Jenkins console when sonar-scanner is executed
ERROR String is not parsed (file DefaultRccSchedulesListPresenter.swift, line 237)
235: }
236: return
237: }
^
238:
239: }
What are you trying to accomplish?
Trying to get rid of the growing list of parse errors thrown by the SonarQube analysis.
Why does this matter to you?
We have spent a lot of time trying to figure out what is wrong in the particular line of code as pointed out by SonarQube analysis. Then the same parse error is getting thrown even for just a bracket in the code, which does not make any sense.
Few years back I remember seeing this issue for the first time and only affecting 1 file in our code base. Over the years the number of files affected by this issue is growing and this is becoming more of a problem, because there is nothing wrong with the line of code as far as we know.
At first we thought this issue has something to do with the file encoding. So we deleted the files affected in which SonarQube was complaining “ERROR String is not parsed”. Then created a new file with the same name and typed in the contents of the file from scratch instead of copy pasting. SonarQube analysis still complains “ERROR String is not parsed”, but the line number is different and just randomly shifting to different line numbers. As far I understood the issue is not at any particular line, something probably wrong with the sonar-scanner or analysis.
How would that look in SonarQube? Alternatives?
Ideally there should be no parse error thrown for a particular line if there is nothing wrong with that line of code.
How would we know it works well?
With our code base we are consistently getting this error thrown every time.
Added screenshot, not sure if that helps.
Why should it be a priority now?
I see a lot of similar issues opened here with the title “ERROR: String is not parsed” with different sonarqube versions. Looks like a lot of people are affected by the same issue and probably investing time into the same issue and later realizing there is no issue in the actual line of code identified by SonarQube.
I’m really sorry you went through this. A parse error simply means that we didn’t understand the syntax, not that there’s anything wrong with the line. As it turns out, we only support through Swift 5.7, which would explain why you’re seeing these errors.
I believe it’s been a while since we gave Swift any love, and I don’t think it’s on the short list right now. Nonetheless, I’ll flag this for the team to see if we can get some attention in this area.
Really appreciate the quick response. Good to know about the language support matrix.
Until recently we were managing SonarQube updates and we have gone through most of the major versions of SonarQube and swift. So I believe at some point we must have had supported swift versions. But we always had this particular issue at least for the part 3 years.
Unfortunately we switched to SonarQube Enterprise Edition recently and it is managed centrally by our parent organisation, so we don’t have the control to update it to the latest version.
I don’t know how to reproduce this issue. But in our code base this issue is consistently thrown for the same files as shown in the screenshot attached.
I could share the files affected, but I don’t want to share the files here publicly. Is there some other way to share code privately?
as already mentioned by @ganncamp, we don’t fully support Swift 5.9 yet.
These are some of the features of Swift 5.9 not yet supported in our analyzer:
Macros
Parameter packs
Variadic generics
If any of those are used in your code, it’s (sadly) expected that you are getting parsing errors. Otherwise, if you could please send me a private message with the file we could investigate further.
In any case, we have already planned a sprint in the coming months to complete the implementation of those missing features, so stay tuned for more
