Implement code select. #76

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
@dragos
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.

Implement code select.
This allows the Javadoc view to track the cursor, and searching for references of the current method under the cursor.
+ val fullClassName = mapType(sym)
+ val results = projects.map(p => Option(p.findType(fullClassName)))
+ results.find(_.isDefined).flatten.headOption
+ } else getJavaElement(sym.owner) match {

This comment has been minimized.

@dotta

dotta Feb 29, 2012

Member

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

@dotta

dotta Feb 29, 2012

Member

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

This comment has been minimized.

@dragos

dragos Feb 29, 2012

Member

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.

@dragos

dragos Feb 29, 2012

Member

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.

This comment has been minimized.

@dotta

dotta Mar 1, 2012

Member

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...

@dotta

dotta Mar 1, 2012

Member

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...

@dragos dragos closed this Mar 2, 2012

misto added a commit that referenced this pull request Jun 14, 2012

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment