Does appCode use LLVM?
The major point of Xcode 4 is its integration with LLVM technology which allows it to have much deeper knowledge of the code that was previously possible. Does appCode use LLVM or a custom code sense engine? (Would be a shame to let LLVM info go to waste.)
Please sign in to leave a comment.
No, we don't use LLVM. Every bit of analysis is written from the scratch.
Wow, that is no small achievement. Preprocessor support, C++ and more? So, all in Javascript Java I imagine?
Oops, been doing too much Javascript code-gen the last few days :)
javascript and java are different languages ;)
Yes indeed - I've been writing a Javascript code generator the last few days, and it's been in my mind way too much :)
In fact appCode does not support C++, only C and Objective-C.
Is C++ (and Objective-C++) on the roadmap?
Not for the first version.
Hi Maxim,
This topic was just bought back to the front of my mind due to a discussion in the Scala forum.
Did you experiment with using the Clang frontend for parsing/analysis and run into problems that precluded it's use?
I'm asking because if you have to redo all of that in your own code, that'll be a lot of additional work that's already been done once, and using the same engine to drive the (basic) analysis as the compiler is using should benefit consistency between editor highlights and actual compiler errors.
The Clang license is liberal enough (BSD or similar) to allow you to embed a version in your distribution, just in case you are worried about the interface breaking due to a new version of Xcode.
I'm also quite stunned that you would replicate all the work done for the Clang analyzer. I'd love to understand the rationale for this.
I could guess at some reasons.
For one thing, the Idea platform which appCode is built on has an analysis and inspection framework already.
For another, if they used the clang analyzer, they would always be at the same level as XCode for inspections, and would not be able to offer more than XCode does without integrating 2 different analyzers.
Lastly, any appCode user has XCode installed as well, so the clang static analyzer results are only a couple of clicks away anyway.
It would be nice to have everything together in appCode, but that's all a matter of priorities and deciding what brings to most value for the hours invested in developing the feature.
Like Matt I'd still be interested in the thoughts of the jetbrains team on this subject.
Maarten, you are quite right on this point. The other point is that with our own implementation we are at full control of it and can adjust, improve and optimize it for our needs.
Clang has its own issues too that we better not have in AppCode.
It also let me, the end user, extends code checking with my own custom inspections :D
But right now, I have an issue with it :( Though it always worked very fine for PhpStorm. Will post about it in plugins forum.
Hi, I would like to reopen this issue since I found something recurring.
So, I used this injection plugin (https://github.com/johnno1962/InjectionIII) that allows me to inject code into a running simulator. However, this plugin requires code coverage settings to be turned off. This is to avoid `Symbol not found: ___llvm_profile_runtime` error.
When I turn off code coverage settings in XCode, the plugin is running smoothly, but on AppCode the `Symbol not found: ___llvm_profile_runtime` error is appearing again even though I have turned off code coverage setting.
Could it be because AppCode uses LLVM?