Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use DefinitionProvider instead of index in RenameProvider #1637

Merged
merged 2 commits into from
Apr 27, 2020

Conversation

tgodzik
Copy link
Contributor

@tgodzik tgodzik commented Apr 17, 2020

Previously, we would use GlobalSymbolIndex, which might not always work for Scala 3 in case of non-parsable code. Now, we use the definitionProvider, which will in turn ask the PresentationCompiler if the definition is missing. For Scala 2 it will still work mostly the same.

The test might fail locally due to issue being fixed scalacenter/bloop#1253, which makes the test fail on even tries 😅

val symbolOccurence =
definitionProvider.symbolOccurrence(source, params.getPosition)
for {
(occurence, _) <- symbolOccurence
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rename symbolOccurence -> symbolOccurrence let's fix this once and for all in this file 💪

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@kpbochenek
Copy link
Contributor

a little unrelated but when I looked at def definition( it contains:

if (result.isEmpty) {
        compilers().definition(params, token)
      } else {
        if (result.isEmpty && fromSemanticdb.isEmpty) {
          warnings.noSemanticdb(path)
        }
        Future.successful(result)
      }

in second if result cannot be empty

}

private def symbolIsLocal(symbol: String): Boolean = {
private def symbolIsLocal(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we could rename it to isLocalSymbol ?

also inside it is symbol.startsWith("local") but we can simply reuse symbol.isLocal which is performing exactly this check.

Copy link
Contributor Author

@tgodzik tgodzik Apr 27, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed, but renamed isWorkspaceSymbol

isLocal
}
def isFromWorkspace = {
val isLocal = definitionPath.isWorkspaceSource(workspace)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for me isLocal has a meaning that symbol is localXXX(anonymous in a given file) and here we talk about isInWorkspace ?

Copy link
Contributor Author

@tgodzik tgodzik Apr 27, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to isInWorkspace

@@ -267,7 +279,11 @@ final class RenameProvider(
}
}

private def canRenameSymbol(symbol: String, newName: Option[String]) = {
private def canRenameSymbol(
symbol: String,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you try to bind symbol with AbsolutePath and propagate them together through multiple functions, maybe it is worth making case class containing those 2 things and just pass one thing. Also it will be easier to see this path is related to this symbol

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay actually I would go with symbol <-> List[AbsolutePath] as it looks like there can be multiple definitions of a symbol. This would fix a problem with <- above

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And then you can decide in symbolIsLocal if given symbol with all definition locations is local or not.
Previously we did .exists which means at least one location must be in workspace, but maybe .all would make more sense here?
I don't know many multi def locations examples, is it only class/trait + object scenario?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we have multiple definitions anywhere currently really. And even if we get one, I can't imagine one being inside workspace and the other outside.

I can rework it a bit, but I don't think we need to add a case class just for 2 methods.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved isWorkspaceSymbol up, so that we don't propagate the path now.

includeSynthetics = includeSynthetic
val allReferences = for {
(occurence, semanticDb) <- symbolOccurence.toIterable
definitionLoc <- definition.locations.asScala
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not go with <- here as it means if you get more locations all references and will be calculated twice for each location

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should most likely go with headOption, but we don't have really currently a situation with multiple definitions.

@kpbochenek
Copy link
Contributor

From what I see you basically replace definitionProvider.fromSymbol(occurence.symbol) with definitionProvider.definition(source, params, token).
Two questions:

  1. Would it make sense to use index and in case of no result fallback to DefProvider?
  2. There are multiple places where definitionProvider.fromSymbol, would it make sense to also change them?

Copy link
Contributor

@kpbochenek kpbochenek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Some comments might not be directly related to changes in code in this PR, ignore if you feel like unrelated)

@ckipp01 ckipp01 added the improvement Not a bug or a feature, but something general we can improve label Apr 23, 2020
@tgodzik
Copy link
Contributor Author

tgodzik commented Apr 24, 2020

From what I see you basically replace definitionProvider.fromSymbol(occurence.symbol) with definitionProvider.definition(source, params, token).
Two questions:

Would it make sense to use index and in case of no result fallback to DefProvider?

DefProvider does it already, uses index to locate the SemanticDB with the definition and then searches that SemanticDB. If it's not available there then we fallaback to PC

There are multiple places where definitionProvider.fromSymbol, would it make sense to also change them?

It might make sense, but before Dotty this wasn't needed. We might need to go through all the functionalities and confirm they're working sensibly in all scenarios.

Copy link
Contributor

@kpbochenek kpbochenek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

Copy link
Collaborator

@mlachkar mlachkar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM too

(occurence, semanticDb) <- symbolOccurrence.toIterable
definitionLoc <- definition.locations.asScala.headOption.toIterable
definitionPath = definitionLoc.getUri().toAbsolutePath
if canRenameSymbol(occurence.symbol, Option(newName)) &&
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OPT: same than Some(newName)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will fix it maybe next time, shouldn't be a big issue.

@tgodzik tgodzik merged commit 85aa6c4 into scalameta:master Apr 27, 2020
@tgodzik tgodzik deleted the fix-dotty-rename branch April 27, 2020 11:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement Not a bug or a feature, but something general we can improve
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants