-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Export diagnostics (including unused warnings) to SemanticDB #17835
Conversation
@@ -3522,7 +3573,7 @@ local1 => val local right: Int | |||
local2 => val local number1: Int | |||
local3 => var local leftVar: Int | |||
local4 => var local rightVar: Int | |||
local5 => var local number1Var: Int | |||
local5 => val local number1Var: Int |
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.
Not sure why they became val
🤔 let me see...
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.
It seems like -Wunused:all
do the thing, maybe we can dig in another issue?
unit.tpdTree.putAttachment(_key, extractor.toTextDocument(unit.source)) | ||
else | ||
unit.tpdTree.getAttachment(_key) match | ||
case None => |
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.
Maybe we should say something when attachment is not found?
@bishabosha Could you take a look when you have time? + Is there any ways to checking the memory usage with this PR (so we can check this PR boost the memory usage of compiler) :) |
if you don't have async profiler there is also https://visualvm.github.io |
Oh, thanks, never mind, I though by any chance, there's a benchmark or something that tracks memory consumption during the benchmark or something. I'll check using some profilers 👍 |
test performance please |
Now, SemanticDB phases doesn't hold the semanticdb info on memory across the phases (AfterTyper - AfterInlining). Instead, I believe that the export diagnostics is more like IO-heavy (only if there're warnings) rather than memory-heavy. It would be nice to test performance using FYI @bishabosha |
do benchmarks exercise the extractSemanticDB phase? Edit: short answer, no. longer answer: looking at https://github.com/lampepfl/bench/blob/master/fixture/profiles/default.plan you can see that custom compiler flags are sent to the note that zinc phases are also not turned on 🤔 |
@tgodzik This PR changes the internal interface of ExtractSemanticDB, and i realized that Metals depends on it |
Thanks @bishabosha for checking! So we may not need to worry too much about performance (and I can't think of any other way to make it faster). Now, it's ready for review 👍 |
We can work around that for sure, besides this will be migrating back to the compiler as soon as @rochala PR is merged. |
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.
Looks good from my side, reading and writing protobuf should be quick enough.
Once this PR scala/scala3#17835 has merged and released, scalafix-organize-imports should be able to run OrganizeImports.removeUnused based on the diagnostics information in SemanticDB emit from Scala3 compiler. In order to make OrganizeImports rule to work with Scala 3, this commit added a few adjustments to the rule.
so the ExtractSemanticDB.PostTyper phase remains the same performance as before, then the ExtractSemanticDB.PostInlining phase adds another 12% to the time taken by the prior PostTyper phase (when I ran on pretty much the entire cost is parsing and writing the text documents, e.g. rather than converting the warnings, so I think once warnings are converted, the reading and writing could be in parallel. |
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.
implementation seems fine other than the question of performance
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.
one annoying thing I found is that e.g. deprecation warnings are not included - these are emitted at crossVersionChecks which is not so long after where the phase is currently placed
compiler/src/dotty/tools/dotc/semanticdb/ExtractSemanticDB.scala
Outdated
Show resolved
Hide resolved
~So, we can use
|
Once this PR scala/scala3#17835 has merged and released, scalafix-organize-imports should be able to run OrganizeImports.removeUnused based on the diagnostics information in SemanticDB emit from Scala3 compiler. In order to make OrganizeImports rule to work with Scala 3, this commit added a few adjustments to the rule.
Despite being |
Current release process is described here. The current backlog of things to asses and backport can be found here. It is expected that there is some delay between things landing on Some of the changes might seem obvious to just cherry-pick to the LTS branch, but there might be other changes that those changes implicitly depend on. I've seen situations like this preparing 3.3.2. This is why it is important to analyze and backport things in the same order as they were merged, even if sometimes it means that you will need to wait for needed changes slightly longer. This particular change will land in 3.3.3 (that should have parity with 3.4.0). It will be available as an RC in late January and as a stable release in early March. |
Many thanks for the extensive answer @Kordyjan 🙇 |
Once this PR scala/scala3#17835 has merged and released, scalafix-organize-imports should be able to run OrganizeImports.removeUnused based on the diagnostics information in SemanticDB emit from Scala3 compiler. In order to make OrganizeImports rule to work with Scala 3, this commit added a few adjustments to the rule.
Once this PR scala/scala3#17835 has merged and released, scalafix-organize-imports should be able to run OrganizeImports.removeUnused based on the diagnostics information in SemanticDB emit from Scala3 compiler. In order to make OrganizeImports rule to work with Scala 3, this commit added a few adjustments to the rule.
Once this PR scala/scala3#17835 has merged and released, scalafix-organize-imports should be able to run OrganizeImports.removeUnused based on the diagnostics information in SemanticDB emit from Scala3 compiler. In order to make OrganizeImports rule to work with Scala 3, this commit added a few adjustments to the rule.
I understand the release cycle is a bit behind, but does the target of 3.3.3 still hold despite no status update on the backport board (still in the "Needs assessment")? Context of my question:
|
I think this should be in 3.3.3, @Kordyjan ? |
Following-up on this to make sure we don't miss the 3.3.4 opportunity (since I believe there is no technical reason that 3.3.3 didn't have it?). I still see this PR as "Needs assessment" in the LTS backport board. I've re-read https://github.com/scala/scala3/blob/main/project/RELEASES.md#how-should-things-be-backported, but I am not sure how we can highlight a particular PR as candidate to the maintainer? |
#20315 🤞 |
fix #17535
What this PR does
This PR splits
ExtractSemanticDB
toPostTyper
andPostInlining
(asChechUnused
does).PostTyper
phaseThis phase does not write the information to a.semanticdb
file; instead, it attaches the SemanticDB information to the top-level tree..semanticdb
file.PostInlining
phasectx.reporter
and attaches them to the SemanticDB information extracted in thePostTyper
phase..semanticdb
file (if there's warning in the file).CheckUnused.PostInlining
phase so that we can extract the warnings generated by "-Wunused".Also,
warnings
in addition toerrors
metac.expect
Concerns