AppCode 2019.2: Swift 5.1, analysis of code coverage by tests, display of disassembled code and more

Astrologers have announced a week of releases at JetBrains, the number of blog posts has tripled! In fact, this is also a release post, so if you participated in EAP, you already know everything.

If not, be sure to check out the cut, because in this release we not only have analysis of code coverage with tests and display of disassembled code, but also DSL support for Ruby and a lot of other interesting things!

Swift

Language support

Started supporting Swift 5.1:

• SE-0242 : Synthesize default values ​​for the memberwise initializer.
• SE-0254 : Static and class subscripts.
• SE-0068 : Expanding Swift Self to class members and value types.
• SE-0260 : Library Evolution for Stable ABIs.
• SE-0258 : Property Wrappers

While in the process, the degree of readiness can be viewed here .

Code folding

Did folding closures:

Backlight

You can’t just take and highlight a line of code without knowing what specific entities we are dealing with. Therefore, full highlighting is possible only after the complete construction of caches. But we know the keywords of the language in advance and can highlight them - now they are highlighted for Swift, even if indexing with caching has not yet ended:

Enumeration Element Generation

We continue to expand the scope of Create From Usage : now you can create an enumeration element from its use in the code, simply by pressing ⌥⏎:

Usage Search

The search for uses in AppCode searches for specific code constructs (variables, classes, functions, class methods, etc.) - this allows you to greatly narrow the search area compared to full-text. Until recently, for Swift, we only displayed where a particular design is used. In 2019.2, we implemented a grouping of uses by type, so now we can quickly understand also how we use a variable, function or class:

Merging lines of code

Nothing special, just now you can glue the declaration and initialization of the variable using Join Lines ( ⌃⇧J ):

Auto Imports

There is such a build system - BUCK . The BUCK build system by default uses header maps, the support of which we added a year ago, but did not have time to throw it into auto imports. As a result, after pressing ⌥⏎, a long path to the header was inserted, which is absolutely unnecessary. Now this does not happen, now everything is correct.

Debugging

Disassembled code display

Colleagues from CLion made the mapping of disassembled code for LLDB in version 2019.1, and we creatively reused it in this release:

Auto completion

Another useful thing originally made in CLion is the autocompletion of debugger commands in the LLDB console by pressing ⇥ (the same as in a regular console):

Test coverage analysis code

Finally done, and done well. We select the test configuration, click Run With Coverage and leave to finalize the tests, we are happy with the result:

To the left in the editor are the coverage results:

By clicking on the color indicator, a plate is displayed with the number of calls in this section of the code and useful actions:

Coverage statistics are displayed briefly in the Project view, and in more detail in a separate window:

Build, run, debug, and test during indexing

Indexing and building caches is not a fast process, especially on large projects and especially the very first indexation. Nevertheless, you can do some actions with the project while it is going on, for example, build or run the application.

For a long time, these actions were blocked for us, because for normal use of the launch configuration it was necessary to first build caches on the project. Actually, this is not so necessary, therefore, in version 2019.2, we decisively untied the creation of launch configurations from caching, and now you can assemble, launch, debug or test the project immediately after its opening:

Integration

TextMate Plugin

Often they are asked to add support for some language, which is not the main one for AppCode. Sometimes we do this if we understand that many users really need it, so at some point we dragged a part of WebStorm to ourselves, so that developers on React Native and PhoneGap would be comfortable working with HTML / CSS / JavaScript.

Then came the plugin for Markdown , because any README needs to be able to conveniently and quickly edit. There is also a plug-in for AppleScript made by one of the colleagues simply because he was interested in writing language support.

But you cannot cram the immensity, therefore we cannot implement support for all languages. For example, in iOS development, DSLs made in Ruby (CocoaPods and Fastlane configs) are often found. Initially, the request sounded like “turn on the entire Ruby support”, but in reality these configs are not often edited, and pulling half-RubyMine because of them does not seem reasonable. At the same time, having no support is not good either.

In this release, colleagues from WebStorm included in the default installation a plugin with support for the TextMate bundles, which gives a bunch of languages ​​a simple highlight and auto-completion. We followed their example, and now we also have this:

Due to some inconsistencies in the support of Fastlane on the part of these bundles themselves, the configuration principle for Ruby DSL is still the same (however, you can help correct this situation).

Shell Script Plugin

Scripts are common in projects, so we have included support for editing them:

Commit window

More precisely, there is no longer any separate window - now it has become part of the Local Changes tab :

This is the end. Write all questions and suggestions right here in the comments - we will be happy to answer!

AppCode Team