Switch to using AnalysisMappers to rewrite zinc analysis #4513
Assignees
Comments
|
Relates to #4477 |
|
Opened sbt/zinc#320 about this being an internal API. Will use it anyway for now, but. |
This was referenced Jul 7, 2017
stuhood
pushed a commit
that referenced
this issue
Jul 18, 2017
### Problem Pants is on an older version of zinc (one that does not use class-based name-hashing), and the modern zinc project is moving quickly thanks to @jvican and others. We had previously been on `X7` but it was reverted in #4510 because benchmarks showed that no incremental compilation was happening for scala code. ### Solution * Upgrade to zinc `1.0.0-X20` * Use the zinc `AnalysisMappers` API described on #4513 to make analysis files portable without parsing * Extract options parsing out of the `Settings` object and into its own module, to allow for reuse in multiple binary entrypoints * Refactor and split our zinc wrapper into `zinc-compiler` and `zinc-extractor` to support parsing the `product_deps_by_src` and `classes_by_source` products directly (in order to move toward making analysis a black box) * Switch to usage of new builder-pattern APIs for constructing zinc objects * Remove the `Loggers`/`Reporters` facades in favor of built in support for filtering log messages ### Result The new version of the zinc wrapper correctly supports incremental compile (with the exception of sbt/zinc#355), and the python portions of pants no longer require any internal knowledge of zinc analysis. The python half of this change will remove that code.
stuhood
pushed a commit
that referenced
this issue
May 11, 2018
### Problem (this change depends on #4728) As described on #4728, we currently need internal knowledge of zinc analysis in order to make it portable, and to extract products that are used by other tasks. Since the zinc analysis format is changing significantly (moving to protobuf, gaining/losing fields, etc), we need to stop parsing it. ### Solution Incorporates the version of the zinc wrapper published in #4728, and uses it in a `analysis.zinc` task to generate the `product_deps_by_src` and `classes_by_source` products from a `zinc_analysis` product published by zinc. Expands the extracted `Zinc` subsystem from #4720 to encapsulate compile dependency calculation, and expose the `FingerprintStrategy` and `DependencyContext` that `compile.zinc` was using. ### Result Zinc analysis is now a black box from the perspective of the pants python code. Also, the `compile.jvm-dep-check` task moved to the `lint` goal, and gained the unused dependency checks that used to be inlined in `compile.zinc` (and which would have prevented separation of the analysis extraction task). Fixes #4477, fixes #4513, fixes #4185, fixes #5444, and hopefully fixes a few other odd incremental compilation bugs.
stuhood
pushed a commit
that referenced
this issue
May 11, 2018
### Problem (this change depends on #4728) As described on #4728, we currently need internal knowledge of zinc analysis in order to make it portable, and to extract products that are used by other tasks. Since the zinc analysis format is changing significantly (moving to protobuf, gaining/losing fields, etc), we need to stop parsing it. ### Solution Incorporates the version of the zinc wrapper published in #4728, and uses it in a `analysis.zinc` task to generate the `product_deps_by_src` and `classes_by_source` products from a `zinc_analysis` product published by zinc. Expands the extracted `Zinc` subsystem from #4720 to encapsulate compile dependency calculation, and expose the `FingerprintStrategy` and `DependencyContext` that `compile.zinc` was using. ### Result Zinc analysis is now a black box from the perspective of the pants python code. Also, the `compile.jvm-dep-check` task moved to the `lint` goal, and gained the unused dependency checks that used to be inlined in `compile.zinc` (and which would have prevented separation of the analysis extraction task). Fixes #4477, fixes #4513, fixes #4185, fixes #5444, and hopefully fixes a few other odd incremental compilation bugs.
stuhood
pushed a commit
that referenced
this issue
May 11, 2018
### Problem (this change depends on #4728) As described on #4728, we currently need internal knowledge of zinc analysis in order to make it portable, and to extract products that are used by other tasks. Since the zinc analysis format is changing significantly (moving to protobuf, gaining/losing fields, etc), we need to stop parsing it. ### Solution Incorporates the version of the zinc wrapper published in #4728, and uses it in a `analysis.zinc` task to generate the `product_deps_by_src` and `classes_by_source` products from a `zinc_analysis` product published by zinc. Expands the extracted `Zinc` subsystem from #4720 to encapsulate compile dependency calculation, and expose the `FingerprintStrategy` and `DependencyContext` that `compile.zinc` was using. ### Result Zinc analysis is now a black box from the perspective of the pants python code. Also, the `compile.jvm-dep-check` task moved to the `lint` goal, and gained the unused dependency checks that used to be inlined in `compile.zinc` (and which would have prevented separation of the analysis extraction task). Fixes #4477, fixes #4513, fixes #4185, fixes #5444, and hopefully fixes a few other odd incremental compilation bugs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As mentioned on sbt/zinc#218, the AnalysisMappers class allows for on-the-fly rewrites of analysis, would allow it to be rebased as it is saved to disk, to avoid the additional decoding/rebasing pass that we currently execute with zincutils.
The text was updated successfully, but these errors were encountered: