Repository navigation
Collect catalog rows where the catalog object compiles - #213
Merged
Merged
Conversation
MyVersions.settings was inline, so its row list expanded into build.sbt (or any caller) at that caller's compile. Neither zinc nor sbt's build.sbt cache recompiles a caller when the catalog it expanded gains or loses a val, so an added row was silently ignored and a removed one failed with NoSuchMethodError. No sbt command clears the cached build.sbt statement. Catalog now takes a CatalogContents given, resolved in the catalog object's own constructor. Its macro walks that object's vals with the same walk coordsOf uses, and the rows are read lazily once the vals are set. coords, pins, actions, ships, and settings are plain methods, so a caller only references them and cannot hold a stale list.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A catalog's rows are collected where the catalog object compiles, so no caller can hold a stale row list.
Why
MyVersions.settingswasinline, so its row list expanded intobuild.sbt, or into anyproject/*.scalacaller, at that caller's compile. Neither recompiles when the catalog gains or loses a val:Evalkeys each compiledbuild.sbtstatement on its text, imports, and SNAPSHOT jars only, never the meta-build's class directory.cleanandcleanFullnever clearproject/target/config-classes.So an added row was silently ignored, and a removed one failed with
NoSuchMethodError. heddle hit the first: a new catalog row was not forced until itsconfig-classeswas deleted by hand.What changes
trait Catalog(using CatalogContents). TheCatalogContentsgiven resolves in the catalog object's own constructor. Its macro finds that object throughSymbol.spliceOwnerand walks its vals with the walkcoordsOfalready uses: parent traits, then the object, in source order, byAsCoords,AsPins,AsActions, andAsShips. The rows are read lazily, after the object's vals are set.coords,pins,actions,ships, andZipxVersions.settingsare ordinary methods, so a caller only references them.object MyVersions extends ZipxVersions, a company trait between them (trait SpliceVersions extends ZipxVersions), and local objects all work as before. A scala-cli miniature proved each shape first.Tests
catalog-winsdrops its workaround, which kept an expansion inside every swapped catalog file. Itsbuild.sbtnow callsMyVersions.settingsandMyVersions.deps(...)directly, and the scenarios that removeoldClientand addsharedpass.sbt "scalafmtAll; cleanFull; testFull": 122 suites passed (core 980 tests).zipxWorkflowCheck: every generated file up to date.plugin/scripted: all 24 fixtures passed.Follow-up
Write up the sbt
Evalcache-key bug for sbt itself, later.