Ok, this will be trickier than I initially thought, but it's good that it was you, Lukas, who reported it :-)

So if there's a Block with "x$1, x$2" that are passed as arguments then it shouldn't be too hard to detect that and restore the named arguments and positions (I'm already doing that for generating source code, just not for building the index). But in the other case when the actual parameters don't need to be reordered before applying then I don't see a way to detect them easily except parsing each Apply tree.. but maybe you know a better way? Is there any indication in the Apply tree that its parameters are being passed "by name"?

Hi Mirko, you are looking at trees after the named arguments transformation, right..? That's problematic then, i don't think it's possible to distinguish an Apply that uses named arguments on the correct positions from an Apply with positional arguments. Named arguments are just removed in that case..

It seems like a general problem - I'm sure you gave this some thoughts already. You'd like to have type-checked trees, but at the same time avoid any transformation done by the type checker, no?

Jep, that's exacly what I'm seeing when I get the AST from the presentation compiler. I guess for now there's not much else that I can do than looking for `=` in the apply args. In the long term a better solution might be needed, at the moment it's just my problem, but sooner or later the IDE will also stumble over this.

> You'd like to have type-checked trees, but at the same time avoid any transformation done by the type checker, no?

Yes exactly, that would be fabulous. And new Tree types for for-comprehensions, etc.. ;-)

> And new Tree types for for-comprehensions, etc.. ;-)

indeed. sounds like a worthy thing to invest time in, type-check the higher-level trees.

however, some of them are already transformed at parsing time (e.g. for comprehensions (i think), anonymous classes). one would have to introduce (and type-check) new kinds of tree nodes..

Maybe some middle ground can be found, like keeping the original Trees from the parser attached to the lower-level trees for the presentation compiler, similar to TypeTree's original. If the KTI project I'm trying to do with Typesafe gets accepted, I might have time to look into this. But for now, parsing the source code looks like the solution.

(In scala-refactoring:79f9d36784eeca3e79984c5fa36429fff24e39c7) Introduce NamedArgument tree to better handle named arguments.

Renaming and Mark Occurrences now also work with named arguments. The
solution isn't pretty: we need to look at the source code to find
named calls and then create instances of NamedArgument trees.

Fixes #77.

Committed to: scala-refactoring:master

(In scala-refactoring:53c8453b69c98981671ae1fdf1daa1bd704d73b3) Introduce NamedArgument tree to better handle named arguments.

Renaming and Mark Occurrences now also work with named arguments. The
solution isn't pretty: we need to look at the source code to find
named calls and then create instances of NamedArgument trees.

Fixes #77.

Committed to: scala-refactoring:named-argument-trees

There seems to be a huge performance problem related to this patch (which I still cannot reproduce), so I had to revert it.