-
Notifications
You must be signed in to change notification settings - Fork 122
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
Feature request: Build and return SourceInfos
when incremental compilation fails
#932
Comments
@Friendseeker Since you closed #1306, should we assume this issue cannot be fixed? |
@adpi2 Might want to double check with the Scala 2 compiler folks but I do suspect this problem cannot be fixed. The issue is that the compiler early stops and does not necessarily return a complete list of all problems in the recompiled files. |
Re-reading your comment in #1306 I think it's fine that some errors are not reported. What I need is a complete view of the reported errors so that I don't have to buffer then in the It's kind of the consensus already: there are some errors, we fix them, and then some more errors can appear. Everybody seems okay with that. So I think we should merge #1306 |
When we bump the AnalysisCallback, we probably want to send PRs to Scala 2.13 and Scala 3 so the Scala teams don't have to figure out what to change. |
Zinc does not provide a way to surface list of all problems present in a codebase. by compiler including the old ones that are deemed valid by compiler and the new ones. This PR builds SourceInfos in Analysis Callback and in `handleErrors`, the compiler bridge then throws an exception containing the SourceInfos so build tools like sbt can access the informations. Closes sbt#932
Just realized there's still work to do. Need to test the below cases. I don't remember my PR covering these cases so probably need to implement these in another PR.
|
c.c. #932 (comment) Just want to confirm with you if these are indeed cases that should be covered. |
Yes indeed, I think we need to cover them both. About saving the Java warnings in the |
Scala compilation problems are recorded in Analysis via calling Maybe Java warnings are already tracked in a way that is different than how Scala warnings are tracked. I will do investigation. |
Note to myself: Document the list of all exceptions Zinc throws and make sure all of them are handled / wrapped appropriately. Maybe we should also create some markdown doc to place the documentation as exceptions are part of Zinc public API. This also helps with informing the build tool authors. This would also help with implementing #1010 (comment). Easy to just throw a random error as but can gets difficult to throw the right type of error at the right place. |
Hi there! When creating a new AnalysisCallback interface version in the future, please ping me, either here on GitHub or on Discord (same username). I'm the maintainer of the Zinc integration in the Scala Plugin for IntelliJ IDEA. I will take care of the rest, thanks! |
When compilation fails, Zinc throws a
xsbti.CompileFailed
which contains:arguments: Array[String]
problems: Array[Problem]
Based on the previous analysis and the
CompileFailed
instance I am trying to build an accurate description of the entire codebase but I am lacking information.I don't know which of the old problems are still valid. Typically, a warning in a file is not reported again if the file is not recompiled, but I don't know if the file has been recompiled or not.
Ideally, the
CompileFailed
exception could contain an instance ofSourceInfos
which would give us the list of problems, the old ones that are still valid and the new ones.At least, as an alternative, I would like to know which files have been recompiled.
The text was updated successfully, but these errors were encountered: