-
Notifications
You must be signed in to change notification settings - Fork 326
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
Lookup method pointers in IDE #5578
Conversation
let method_pointer = node_info.method_call.as_ref().ok_or(NoResolvedMethod(node))?; | ||
Ok(Rc::new(method_pointer.clone())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to avoid this clone: let's store the method pointer in the ComputedValueInfo under Rc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes on the JVM side look sane. Using method pointer in the protocol is more human readable and still exact enough to identify the right method. The conversion of method pointer on the IDE side doesn't look complex either.
I like the change.
@@ -324,7 +324,7 @@ interface ExpressionUpdate { | |||
/** | |||
* The updated pointer to the method call. | |||
*/ | |||
methodPointer?: SuggestionId; | |||
methodPointer?: MethodPointer; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the (major) API change: Instead of using SuggestionId
to identify a method, we are using MethodPointer
.
|
||
} | ||
.pipeTo(sessionRouter) | ||
val computedExpressions = expressionUpdates.map { update => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code is simplified. Instead of trying to find a suggestion id we just send a tripple (module, type, methodname)
* @param profilingInfo profiling information about the expression | ||
* @param fromCache whether or not the expression's value came from the cache | ||
* @param payload an extra information about the computed value | ||
*/ | ||
case class ExpressionUpdate( | ||
expressionId: UUID, | ||
`type`: Option[String], | ||
methodPointer: Option[Long], | ||
methodPointer: Option[MethodPointer], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will probably increase the size of ExpressionUpdate
messages - instead of a number we send the tripple with three strings, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the MethodPointer
is a triple containing module, self type, and method name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Engine changes look sane
} | ||
} | ||
|
||
def toProtocolMethodPointer(methodPointer: Api.MethodPointer): MethodPointer = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't ContextEventsListener
just make that method public (or protected, if sufficient)?
That would eliminate duplicate method.
Pull Request Description
Closes #5036
Move the logic that looks up method pointers from the language server to IDE. This way we can keep the suggestion updates and expression updates async, otherwise it will hurt the initial startup time of LS.
Fixes the issue when some expression updates does not contain the method pointer.
Important Notes
Checklist
Please include the following checklist in your PR:
Scala,
Java,
and
Rust
style guides.
./run ide build
and./run ide watch
.