Debugging Lambdas and Macro Expansion Extractor

We have released a new EAP version of the Scala plugin for IntelliJ IDEA 15 EAP. Here is a couple of new features we have added:

Debugging: stopping at Lambda Expressions

When you add a breakpoint to a line that contains a lambda expression, the IDE offers you several options where it should stop. Choose any lambda expression if there are several of them, or stop at the whole line. You can use the Run to cursor function on a lambda expression as well.


You can use Ctrl+F8 to add a breakpoint. Then the lambda expression that the cursor is placed on will be selected in the list. Pressing Ctrl+F8 again will complete creating a breakpoint on the selected lambda.

Macro Expansion Extractor

Sometimes it’s useful to extract a macro expansion in the place where you are using it, which can help you debug the macro. Before using this, compile the code with “-Ymacro-debug-lite”.


Press Ctrl+Alt+Shift+Z with the cursor placed on the macro.


If the cursor is not on a particular macro, all macros in your file will be expanded.

Please, share your feedback in our discussion forums and issue tracker.

Develop with Pleasure!

This entry was posted in EAP, New Features and tagged , , . Bookmark the permalink.

7 Responses to Debugging Lambdas and Macro Expansion Extractor

  1. TD says:

    Hooray, the in-lambda comments are awesome. Now, let’s take the next logical steps and

    – put the breakpoint mark not to the left column, but to where the breakpoint actually is

    – allow more than one breakpoint on a line

    – allow the breakpoint to be inserted anywhere (not only beginning of line or the lambdas, but any expression on the line).

    – while debugging, highlight the expression that is going to be executed next (the highlighting could look the same way the lambda breakpoint is highlighted now), so we don’t have to dig through the ($meaningless$anon$func$3) stacktrace all the time

    – make “Step over” step not over the current line, but over the expression that is going to be executed next. Lines are completely artificial to the formatting, respect the code, not the layout.

    With at least these improvements, the debugger might actually become usable. With a more complete rethink (in my bogoguess 10+ years), it could even come close to what (VisualWorks and others) Smalltalk debugger could do for decades.

    • TD says:

      Sorry, the first line should obviously state “in-lambda breakpoints”, not “in-lambda comments” :(

    • Nikolay Tropin says:

      Hi, Tomas,
      Thank you for your suggestions. I’m not sure I got your idea about putting breakpoint where it actually is. How it should look?

      Support for multiple breakpoints on a line will certainly be done at some point. We just need to find a good UI for it. Any ideas?

      Stopping at any expression would be great, but it is not possible with the debug information provided by scala compiler. Lambdas are special because they are compiled into a separate entity.

      Debugger does not know expression which will be executed next until it gets executed. It could be guessed in simple cases, but I think it is not reliable and not very helpful.

      Step over could definitely be improved, but it would be better if you’ll provide concrete cases where you think it should work differently. This also applies to obscure methods in the stacktrace. We are trying to filter them out, but we’d like to do better. Such things are better to discuss on our issue tracker:

      I created issue about multiple breakpoints on a line:

  2. TD says:

    OK, I’ll try to find time to elaborate on some points on Friday. Thank you for considering my suggestions! Tomas

  3. TD says:

    I have very little time and I won’t be at the internet during the following two weeks, but I’ll hopefully try to sketch how I’d like the debugger to look like.

    There is a mockup I’ve created at

    It shows an in-line breakpoint, and three steps of debugging on three consecutive pictures. I forgot to also put the breakpoint on the second and third picture, but it should be there until you remove it.

    On the first picture you can see I’ve placed the breakpoint just before calling the “sum” function, I’m probably curious about the total age. The breakpoint mark is inserted directly in the text (which is indented a bit to provide the space for it), so you can immediately see where the debugger will stop.

    The sum function is highlighted (with a different highlighter than just a text selection), which means that it is that function that is going to be performed next. The user has (at least) two choices now: Step into and Step over. Step into would dive into the body of the sum function, Step over would just perform the sum function (but nothing else!). Let’s press Step over, now we are at the second image. The sum function has been executed, and the next function to be executed at this level is the people.size function. Again, the size method is highlighted to indicate that it is going to be executed next. Let’s press Step over again and get to the third picture that shows that a division is going to be performed next, as it is highlighted along with its arguments (people.size).

    I know this is hard to impossible given the current tools, but the fact that such a basic debugging experience is not available impairs productivity heavily. I think you could highlight the next-to-be executed expression, given you have at your hands the stack, the instruction pointer and you know scala syntax. That would at least make up for the impossibility to place a breakpoint at an arbitrary point.

    If you want further inspiration, please try to find some videos about debugging with Smalltalk – either VisualWorks, or Pharo. Imagine some of the following:

    – being able to have several debugging windows and inspectors open at the same time
    – ANY text editor also acting as the “Evaluate expression” window, along with the appropriate context (where you can evaluate multiple statements at once)
    – being able to modify the code (methods, classes, …) while debugging to test out new implementations
    – all the commands (Step in, step over, …) executing instantly without a noticeable lag even on slow hardware


  4. Schmitt Christian says:

    Test improvments are cool, but as long as the Specs2 Testing doesn’t work all the time it’s aweful, it should definitly make more use of sbt, than the IntelliJ compiler.
    On Play2 projects either JUnit and Specs2 /ScalaTest mostly fails inside the IDE, while it works on the console.

  5. Ashish says:

    Hi, is there a way to enable the tooltip debug value for scala code in Intellij? Can’t find it anywhere ( I am using the latest scala plugin – 2.2.0)

Leave a Reply

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