Support zinc name hashing.

Review Request #1779 - Created Feb. 16, 2015 and submitted

Information
Benjy Weinberger
pants
7bd1a93...
Reviewers
pants-reviews
nhoward_tw, patricklaw
- Upgrade to a recent version of zinc.
- Support version 5 of the analysis serialization format.
- This version moves the CompileSetup sections from the end of
the file to the beginning.
- This version adds a "name hashing" section to the CompileSetup.
- Add a pants option to turn name-hashing on.
-  Fixed the implementation of is_nonempty_analysis(), which can no
longer simply look at a prefix (because the order of elements in the zinc
analysis file has now changed).

We had already added support for splitting/merging the analysis sections
used by name hashing, under the assumption that their structure and semantics
were the same as for their equivalent pre-name-hashing sections.  We had been
told by TypeSafe that this assumption was correct, but had never tested it.
I have now verified that it is indeed true.

Note that when name hashing is turned on, the member* and inheritance* sections
are populated by zinc INSTEAD OF the direct* and public* sections. However the
"used names" section is populated AS WELL AS the "class names" section. This means
that turning on name hashing will cause analysis files to be larger. Whether this
is significant, in particular wrt split/merge times, needs to be measured. I suspect
it should be OK, since split/merge of these sections is simple - they don't have
the complicated internalization/externalization logic.

CI passes: https://travis-ci.org/pantsbuild/pants/builds/50907336

Issues

  • 0
  • 6
  • 4
  • 10
Description From Last Updated
Stu Hood
Patrick Lawson
Benjy Weinberger
Benjy Weinberger
Nick Howard (Twitter)
Stu Hood
Benjy Weinberger
Benjy Weinberger
Review request changed

Status: Closed (submitted)

Stu Hood

It looks like this change does not cause the buildcache hash to change, so if the cache fetches an artifact generated with the previous version, it fails with:

FAILURE: Unrecognized version line: format version: 4

I guess the tool bootstrap identity isn't included, but should be?

  1. Hmm. At least the format version should be. The tool identity might be overkill, as every upgrade will invalidate every artifact.

  2. A workaround is to bump the cache key generation in pants.ini. This will invalidate every artifact (not just scala ones) so it's a bit extreme.

  3. Wait, it looks like the tool jars are in the key. See platform_version_info() in scala_compile.py. Weird.

  4. It looks like the platform jars use the scala version, but not the zinc version. Will open a review to include that. Thanks!

  5. Opened https://rbcommons.com/s/twitter/r/1858/

Loading...