AppCode starts 2016.2 EAP: Swift inspections and Live Templates, improved Rename for the mixed code and more!

Hi everyone,

Today we are starting the Early Access Program for AppCode 2016.2 EAP, with a huge number of changes available in the very first build. You’ve waited for some of them for a long time, so check it out right now!

Swift

SourceKit inspections and intentions

This build brings one of the long-awaited features from our roadmap – initial implementation of inspections and intentions in Swift. Now AppCode shows warnings and errors for Swift code in the editor right as you write it!
Swift warnings and errors in editor

To display these warnings and errors, AppCode uses SourceKit engine bundled in the Xcode version selected in AppCode settings. Moreover, most quick-fixes available for Swift in Xcode can now be used in AppCode. Just press ⌥Enter on a warning or error and select Apply Fix-it:
Swift quick-fixes
In case of several fix-its suggested for a particular code block, AppCode will display their descriptions, allowing you to select the necessary action:
Multiple Swift quick-fixes
Inspection settings are available under Preferences | Editor | Inspections | Swift | SourceKit inspections, where you can turn it on or off at any time:
Intention settings
SourceKit inspections are also available in batch mode, and here you can fix every problem step by step. For now it’s even easier with improved UI for code inspections available in this version:
Batch mode

Live Templates

Live Templates in AppCode are similar to Xcode snippets. They contain predefined code fragments so that you can use them to insert frequently-used or custom code constructs into source code quickly. Starting with this build, Live Templates are also available for Swift language:

  • Invoke a Live Template by typing its abbreviation, or use ⌘J and select it from the list:
    Live template calls
  • Quickly iterate collections with the smart for template:
    For template

You can also add your own custom Live Templates for Swift under Preferences | Editor | Live Templates | Swift. Select predefined code context to make your live templates available only for Swift declarations, statements or any code construction:
Live templates context

Spelling inspection

In addition to the SourceKit inspections mentioned above, we decided to make the Spelling inspection available for Swift language. If you happen to mistype something in your comments or code constructs, AppCode will underline the misspelled word. Then you can fix the problem simply by pressing ⌥Enter:
Spellchecking

Recursive resolve for shorthand arguments in closures

This feature had one of the shortest descriptions in our tracker, one simple line:

Nevertheless, it was a huge task we needed to finish as part of preparation for creating Introduce Variable and Inline Variable refactorings for Swift. This build contains an initial implementation of recursive resolve for closures in Swift, including correct resolve for shorthand arguments. This change brings the following features:

  • Now you can benefit from completion for shorthand arguments:
    Shorthand completion
  • In case the closure contains tuple as parameter, you can navigate to the actual declaration of the tuple item:
    Navigation

Please note that some issues with closure resolve still exist; most of them are added as sub-tickets to the base task. We will continue to work on them and will try to resolve the most important ones before the 2016.2 release.

Mixed code improvements

It’s been awhile since we implemented the Rename refactoring for pure Swift code and Objective-C declarations used from Swift. Now we add the ability to rename Swift methods and method parameters used from Objective-C code! Let’s take a quick look at it:

  • If using Swift methods from Objective-C, you now can invoke Rename on the method name:
    Rename Swift from Objective-C
  • To rename external or local parameters, invoke Rename from Swift code:
    Rename Swift parameters
    Notice how Objective-C representation was correctly updated in Objective-C code.

Another great addition in this build is improved Find Usages (⌘F7) functionality, which now also finds occurrences of Swift methods used from Objective-C, including initializers.

There are also lots of fixes for code declarations annotated with @objc attribute, bringing improved parsing and highlighting for classes, protocols and enums, and correct resolution for properties, subscripts, getter and setter names.

Objective-C/C++

Doxygen support

You may know that AppCode and CLion teams work together to bring you first-class C++ support in both products. But sometimes C++-related features also intersect with Objective-C, and one such feature recently implemented by the CLion team is initial support for Doxygen. For now, the same features are available for C++ support in AppCode and some of them have already been added for Objective-C as well:

  • You can now benefit from completion for Doxygen-style commands in Objective-C comments:
    Doxygen commands
  • The formatting for Quick Documentation (F1) is significantly improved with proper rendering for all Doxygen-style comments:
    Quick documentation

Please note that because of some issues, automatic comment generation for Objective-C is not yet included into this build, but we will try to deliver this feature before the 2016.2 release.

Complete statement

With Complete Statement (⇧⌘Enter) feature added in this build for Objective-C and C++, AppCode inserts parentheses, braces, semicolons, quotes, etc. for you where necessary, and then moves the caret in position where you can start typing the next statement automatically. The simplest example can be just adding a semicolon, but even this small feature can be helpful in case of complex code constructions:
Complete statements

Read this blog post to learn more about it.

Debugger

In debugger tool window, the Watches and Variables modes are now merged so you don’t need to switch between them. If you still prefer the old style, a new button is available in the watches toolbar to switch between the modes (new mode is on by default):
Debugger

VCS improvements

The following changes are available for VCS support in AppCode:

  • To make navigation through the VCS log easier, we’ve added tooltips with target commit information for arrows:
    Tooltips for commits
  • Commit dialog now also shows unversioned files:
    Unversioned files
  • Support for Apply somehow interactive mode for applying patches.
  • Git/Hg log shows commit details for several selected commits.

Phew, that does it! Full release notes for this build are available here. This being an EAP for a major update, the build does not require an active license so you can use it free for 30 days.

Download AppCode 2016.2 EAP, give it a try and let us know what you think!

Your AppCode Team
JetBrains
The Drive to Develop

This entry was posted in Announcement and tagged , . Bookmark the permalink.

25 Responses to AppCode starts 2016.2 EAP: Swift inspections and Live Templates, improved Rename for the mixed code and more!

  1. Tropper says:

    Yay! Can’t wait to test it!

  2. Michał says:

    Great job, guys! Waiting for even more Swifty goodness!

  3. Bill A says:

    YEEEES!

  4. Dev says:

    The shorthand closure argument feature doesn’t seem to be working, even in a simple example like this:

    var test = [“”, “”, “”]
    test.forEach {
    $0.^no suggestions^
    }

  5. David Whetstone says:

    Hmm, with SourceKit still being extremely crash prone, I’m not so crazy about this idea.

    • Vyacheslav Karpukhin says:

      SourceKit analysis is performed out of process (both in AppCode and Xcode), so the crashes will not affect the IDE itself.

      • Chris Hatton says:

        Out of keen interest, is SourceKit the long-term solution for real-time inspections in AppCode; or do you intend to switch back to your own parser (which I believe could be even better) once your language model is stable and complete?

        • Vyacheslav Karpukhin says:

          I apologize for a late reply.

          Currently SourceKit and our own parser work side by side. SourceKit is used only for the error reporting, the same way as clang-annotator is used for Objective-C.

          Our own inspections and refactorings do not depend on SourceKit.

  6. Rick says:

    is intenseness that bad?

    something as simple as
    let x =5
    x = 6

    why doesn’t it show any error or even
    var x =5
    no_var_name

    nothing, is this normal or something missing.

    Thanks

    • Stanislav Dombrovsky says:

      Hm, it can happen if syntax analysis is in progress. After it warnings and errors should be displayed. Could you please give us a screenshot of top-right corner of the editor area?

    • Dev says:

      I agree that this is totally broken in the EAP. I can see in the SourceKit logs that the errors are being reported, so AppKit’s SourceKit requests are correct, so either there’s a bug in how those are being processed by AppCode, or – more likely – all the internal errors that I can see AppCode generating on each editor keypress are getting in the way. I’ve reported these errors through the in-app mechanism, but I’ll include them here for reference:

      [ 387874] ERROR – aemon.impl.PassExecutorService – @NotNull method com/jetbrains/cidr/lang/symbols/objc/OCProtocolSymbolImpl.getType must not return null
      java.lang.IllegalStateException: @NotNull method com/jetbrains/cidr/lang/symbols/objc/OCProtocolSymbolImpl.getType must not return null
      at com.jetbrains.cidr.lang.symbols.objc.OCProtocolSymbolImpl.getType(OCProtocolSymbolImpl.java:50)
      at com.jetbrains.cidr.lang.symbols.objc.OCMethodSymbolImpl.getReturnType(OCMethodSymbolImpl.java:200)
      at com.jetbrains.cidr.lang.symbols.objc.OCMethodSymbolImpl.getReturnType(OCMethodSymbolImpl.java:211)
      at com.jetbrains.swift.symbols.SwiftObjcSymbolConverter.convertMethodSymbol(SwiftObjcSymbolConverter.java:499)
      at com.jetbrains.swift.symbols.SwiftObjcSymbolConverter.doConvertMember(SwiftObjcSymbolConverter.java:470)
      at com.jetbrains.swift.symbols.SwiftObjcSymbolConverter.access$100(SwiftObjcSymbolConverter.java:56)
      at com.jetbrains.swift.symbols.SwiftObjcSymbolConverter$3.fun(SwiftObjcSymbolConverter.java:461)
      at com.jetbrains.swift.symbols.SwiftObjcSymbolConverter$3.fun(SwiftObjcSymbolConverter.java:458)

      • Stanislav Dombrovsky says:

        This error is not caused by SourceKit response processing, it’s known issue, most probably caused by mixed code changes. Could you please describe how it affect the parsing/highlighting/displaying errors in your case? Is it possible for you to give some code sample (except mentioned in the issue description) to show may be some other side-effects?

        • Dev says:

          Ah I see. I created a new project and I didn’t get the above stack trace on every keypress, and I can see now that the SourceKit diagnostics are showing correctly, including in Rick’s example. So perhaps it is the case that the above stack trace is indirectly the cause of the SK diagnostics not showing up in my regular project.

          Unfortunately I can’t send my regular project, but if I identify code that causes the issue, I’ll let you know.

          Until I created a new project just now, the EAP seemed very buggy, but I can see now that the new features are working well, it’s just that this bug is getting in the way. I hope you treat this as a high priority as it does totally break the editor.

  7. Tadeas Kriz says:

    I’m looking forward more Code Style features. Right now I’m not able to use AppCode as I can’t setup the Code Style to match our team’s style. For example, there doesn’t seem to be a way to have closures look this way:

    { param in
    // executed code
    }

    and instead they look like this:

    {
    param in
    // executed code
    }

    Are there any plans to improve this? Thanks!

    • Stanislav Dombrovsky says:

      Most probably we will not be able to deliver code-style formatting features in the 2016.2 release, but we will consider code-style features for the next. Please, upvote this issue

  8. Pikor says:

    This is really great news!
    However after opening project (100% Swift) AppCode is “Indexing” for infinite amount of time. Any ideas? :/

  9. Talles says:

    Love you guys <3

  10. I have a typealias:
    typealias CompletionBlockAPI = ((Result) -> ())?

    and a method that use this typealias:
    static func delete(creditCard: CreditCard, completionHandler: CompletionBlockAPI) { … }

    When I call this func the type of completionHandler is not recognized

    API.Users.CreditCards.delete(crediCard, completionHandler: { (result) in

    }

    Are there any plans to improve this? Thanks!

    • Stanislav Dombrovsky says:

      Could you please give a screenshot of how it isn’t recognized? Do you mean type in the completion popup for result when using it inside the closure or smth else?

Leave a Reply

Your email address will not be published. Required fields are marked *