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

Allow clicking through to source of mutability reason #43

Open
Grundlefleck opened this issue Aug 27, 2013 · 2 comments
Open

Allow clicking through to source of mutability reason #43

Grundlefleck opened this issue Aug 27, 2013 · 2 comments

Comments

@Grundlefleck
Copy link
Contributor

Currently, when a unit test fails, it displays all the reasons a class is mutable. Each reason is printed with a location, the 'primary' source of mutability, for example, [Field: hash, Class: java.lang.String] for the hash field that can be reassigned. A user will have to read this then navigate to the file and field themselves.

Text output in test failure shown here:

current_source_code_location_arrow

We can do more to make it easier to find the source of mutability. At least two of the three major IDEs (Eclipse and Intellij, not checked NetBeans) have functionality that interprets elements of a stack trace, to allow clicking through to source.

Like here:

Eclipse:
eclipse_linking_to_source_arrow

IntelliJ:
intellij_linking_to_source_arrow

This is achieved by having a string which matches a particular format, like:
at java.lang.String.<init>(String.java:105)
(the "at", with that casing, is significant).

We could take advantage of this trick in the IDEs to allow us to print locations which are clickable.

This issue would represent three bits of work:

  • making sure that every reason also prints a location which matches this format, such that it can be clicked through
  • an audit of all existing checkers, to make sure that they provide the most appropriate location for the reason (e.g. for reassigned fields, do we point to the field, or where it's reassigned?)
  • potentially doing extra bytecode analysis, to find the class, method, and line number of the most suitable location for the reason
@jagan387
Copy link
Contributor

jagan387 commented Jun 1, 2016

Since we have #46 separately, does that mean we can fix the linking, and close this bug? If so, i can submit a fix right away

@Grundlefleck
Copy link
Contributor Author

By "fix the linking" do you mean a code change that will print out the format that becomes a link, but not the change to provide accurate numbers? I think that would be a reasonable chunk to contribute. Perhaps there should be a class/interface/datastructure that can be created (if it doesn't already exist) that can be printed out, but maybe just is created with dummy line numbers for now, but can be filed in accurately when #46 is complete.

Would be happy to merge that part separately.

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

No branches or pull requests

2 participants