-
Notifications
You must be signed in to change notification settings - Fork 18
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
Enrich the debug info with source files for implicit searches by type #49
Conversation
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.
LGTM (within the limits of my limited knowledge of this repo, anyway)
I tried this and I don't understand what |
Is it possible to add the line number alongside the file name? Like |
How do you work with that debug output? For my usage, it's no more than just text and not valid code at all 🤔
The issue is that a single file could contain multiple implicit searches for the same type, so we must account for that information. Also, according to the reflect API, we could have not only the single-point position but ranges too. It seems that the output can become verbose and difficult to read. |
Sure, but what is the meaning of the second string? I tried it on a 200KLOC codebase and it was always an empty string. |
I understand. But with files with thousands of LOC this is not very useful since the definition can be anywhere. One note for the future. It would be nice if this information was written to a file instead of printed to the stdout. I need to do |
I also thought about this one 😄 I wasn't just sure about the approach to managing this. Like, we can ask for the location for that debug file. But it seems we're going to ask so many locations from users: source root, target, debug file. But I don't mind iterating over this since I've tried to enhance the current output data at this run. @lolgab from your perspective, what output format does fit the debug purposes best (considering adding the positions info)? |
Yes, it can be iterated over later.
I would use the same format printed by the compiler: It's nice because if you command+click from an IDE it will move you to the exact line. |
So, instead of having a set of file names, you're suggesting adding a list of paths containing positions, right? But I was about the whole output, which is currently a |
@lolgab any further thoughts on this? |
ping @lolgab |
I plan to revise what I did here a few months ago in light of @lolgab's comments and some changes in my mindset. |
@SethTisue Sorry for my late response. |
@lolgab I've thought about this PR and your suggestions. I agree that debugging the output built by the
And with this PR, we are going to add:
Given all of this, it'd break the coherency of that option if we make the output just of the 'Implicit searches by type' to be logged into the external file. Instead, let's bring another option, say 'export-profiles', that will prepare the output in a human-readable format. I opened #105, and it'd be exciting if you could write your thoughts there. For this PR, I'm willing to keep the |
So, given my previous comment, the ultimate output will have the following format:
Yeah, it's still not super convenient to explore SBT's output, but at the very least, it will be aligned with the entire output produced by the existing compiler plugin option. All other work to make the output more accessible will be done within #105. |
Resolves #44
In #44, @lolgab suggested adding info about source files to the flamegraph. In fact, this could make the flamegraph unreadable (imagine putting the dozens of strings like
/Users/foo/projects/bar/src/main/scala/baz/qux/quux.scala
to the single cell). Here, I'm suggesting another approach to tackling the root issue — assisting in determining the source files for the particular types in implicit searches.Current state
We already have the compiler plugin option
-P:scalac-profiling:show-profiles
that prints the debug info to the output:But it's lacking the info about the source files to peek at.
Proposed changes
This PR modifies the output by bringing the source files alongside the number of firings for the particular types in implicit searches.