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

Fix for setting breakpoints in async code. #360

Closed
wants to merge 1 commit into from

Conversation

sannysanoff
Copy link

this fixes long standing issues with stepping through and setting breakpoints in the scala/async async code.

bug happens because NamePattern.forElement(elem) returns nothing for async psi elements, and as a result method returns zero candidate classes for given SourcePosition.

nothing in NamePattern.forElement(elem) is returned because it doesn't know that async methods generate classes (in our case, classes generated are named Basename$statemachine$...). I think the logic that filters out our case in NamePattern.forElement(elem) should be improved but I don't know how.

but creating NamePattern directly helps. Although filter is more loose and may falsely accept more cases, hasLocations(refType: ReferenceType, position: SourcePosition) seems to be strict enough to filter out the only one correct class from generated statemachine. I wonder what could be the cases that are falsely accepted.

Environment for which it fixes bug:

scala-async_2.11 0.9.6-RC2
idea162.x branch as of today
scala 2.11.7

maybe fix for scala/scala-async#136
and for https://youtrack.jetbrains.com/issue/SCL-4935

best regards.

…akpoints in the scala/async async code.

bug happens because NamePattern.forElement(elem) returns nothing for async psi elements, and as a result
method returns zero candidate classes for given SourcePosition.

nothing in NamePattern.forElement(elem) is returned because it doesn't know that async methods generate classes
(in our case, classes generated are named Basename$statemachine$...). I think the logic that filters out
our case in NamePattern.forElement(elem) should be improved but I don't know how.

but creating NamePattern directly helps. Although filter is more loose and may falsely accept more cases,
hasLocations(refType: ReferenceType, position: SourcePosition) seems to be strict enough to filter out
the only one correct class from generated statemachine.
@sannysanoff
Copy link
Author

sannysanoff commented Jul 9, 2016

The example code is this:

  def handleSystemConfigurationRequest(req: Boolean): Future[DatabaseResponse] = async {
/*[BP here]*/    val config = await(singleSelect(q"""         select ...          from ....           """))
    new DatabaseResponse(
      result = REQUEST_PROCESSED,
      systemConfigurationResponse = Some(SystemConfigurationResponse( ...)))
  }

In fact, the only case where this example worked (once) is when I set breakpoint and THEN launch application. The notification from java debugger (causing processClassPrepare() and friends inside IDEA) results in setting correct breakpoint. But after class is loaded, clearing and setting breakpoint DID NOT work, because execution in IDEA goes to different branch in createOrWaitPrepare() function, which did not work (before this patch).

@niktrop
Copy link
Contributor

niktrop commented Jul 13, 2016

Thanks for pointing to this issue and a suggested solution. But I think that we need to compute an appropriate NamePattern in the first place. Please try if this fix works in your case:
b0875be

If you'll have any problems with it please let me know.

@niktrop niktrop closed this Jul 13, 2016
@sannysanoff
Copy link
Author

If idea caught up my new zip correctly, your patch seems to work!

thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants