Skip to content

Implement code select. #76

Closed
wants to merge 1 commit into from

2 participants

@dragos
Eclipse Scala IDE member
dragos commented Feb 29, 2012

This allows the Javadoc view to track the cursor, and searching for references of the current method under the cursor.

It's part of my clean-up effort of branches that hang around my checkout. I think this one is generally useful and adds some convenience when working with Java APIs, plus it cleans up something that never worked.

@dragos dragos Implement code select.
This allows the Javadoc view to track the cursor, and searching for references of the current method under the cursor.
1d78669
@dotta dotta commented on the diff Feb 29, 2012
...cala/tools/eclipse/javaelements/ScalaJavaMapper.scala
+ askOption { () =>
+ ((meth.getElementName == sym.name.toString)
+ && meth.getParameterTypes.map(tp => getTypeErasure(getElementType(tp)))
+ .sameElements(sym.tpe.paramTypes.map(mapParamTypeSignature)))
+ }.getOrElse(false)
+ }
+
+ if (sym.isPackage) {
+ val fullName = sym.fullName
+ val results = projects.map(p => Option(p.findPackageFragment(new Path(fullName))))
+ results.flatten.headOption
+ } else if (sym.isClass || sym.isModule) {
+ val fullClassName = mapType(sym)
+ val results = projects.map(p => Option(p.findType(fullClassName)))
+ results.find(_.isDefined).flatten.headOption
+ } else getJavaElement(sym.owner) match {
@dotta
Eclipse Scala IDE member
dotta added a note Feb 29, 2012

isn't sym.owner risky? (I mean executing it outside of the PC)

@dragos
Eclipse Scala IDE member
dragos added a note Feb 29, 2012

It shouldn't be. The scala compiler uses laziness only in types, not in symbols... Every symbol has an owner, since they are always created through factory methods, like owner.newValue or owner.newClass. That being said, to my great surprise TypeTree.symbol is delegating to its type to retrieve the symbol. However, that looks like a bug or an exception and I'm willing to take a risk here for the owner. As soon as we get the API (yeah, I know, it sounds like empty promisses), this can be switched to the 'safe' API.

@dotta
Eclipse Scala IDE member
dotta added a note Mar 1, 2012

In the compiler I remember seeing phases changing the owner in some cases, that's what made me thinking. But I guess that owners don't change if only phases up to typer are run.

Looking forward to the API, we will finally be able to fix quite a bit of code. We really have way too many places were we can suffer visibility issues because we access compiler's data structures that are not thread safe...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@dragos dragos closed this Mar 2, 2012
@misto misto added a commit that referenced this pull request Jun 14, 2012
@misto misto Create fatal errors when a refactoring's initial check yields an error.
Until now, we created normal errors, which were shown in a wizard page,
and because they were non-fatal, the refactoring still tried to execute,
resulting in exceptions in the log file. Now we use fatal errors, which
immediately abort a refactoring and show the error message in a window.

Fixes scala-refactoring #76
0ae24d2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.