Verify that lint is wconfable

[som-snytt]

Fixes scala/bug#12985

Emits the warning in a lint category.

Adds an internal feature for partest: using test.option --recompile allows checking that a neg test turns pos when recompiled with an additional option (-Wconf:something).

toolArgs is teased apart to encourage using syntax, which is easier to parse (than checking for all the tool names).

[som-snytt]

I think dotty test rig has a mechanism for "test with and without flag"; at some point it resulted in an explosion of test runs, which points to its facility.

Here, it would be nice to automate that neg test has -Xlint:foo so test with -Wconf:cat=lint-foo:s. But I grew fatigued.

Worth noting that I added a pos test from OP on another branch last week, so I added it locally and mistyped it: I forgot any is a filter not a category. After figuring that out, I wasn't sure it was worth adding the test file.

I know the useful actions s, w, and e, because I am a SWE.

[som-snytt]

how about //> using retest.options -Wconf:cat=lint-cloneable:s. Leverage the "scope"; don't pollute semantics of test.options which I assume means compile options for tests, which is technically redundant here; also avoids the awkward --recompile; but the semantics of retest are constrained, as it doesn't mean "retest as neg" but "as pos", or maybe it would also invert pos to neg on retest.

[som-snytt]

@SethTisue java.io.IOException: No space left on device. Does this thing actually ring your phone?

This evening while watching the Great Courses disc on American History, I learned about the War of Jenkins' Ear, which must interest you for the obvious and only reason.

[lrytz]

I deleted the coursier cache for now

/home/jenkins/.dbuild/cache-0.9.20 is 71 GB (the disk has 400)
Most usage is probably in jenkins workspaces (eg /home/jenkins/workspace/scala-2.12.x-jdk17-integrate-community-build/target-0.9.20/extraction/).

[SethTisue]

Yeah the usual solution is to blow away community build workspaces. We do blow away the dbuild cache occasionally but it's needed less often.

[lrytz]

Yeah the usual solution is to blow away community build workspaces

👍 can this be done at any time or does it cause more work for you right now close to the release?

[SethTisue]

can this be done at any time or does it cause more work for you right now close to the release?

if I'm unavailable (as I was for 24 hours or so in this case, though I'm now available again) you should feel free to just do it

if I'm available, I can sometimes be selective about only blowing away a workspace that doesn't have partial results that we'd prefer to keep in order to save time. but it's only about saving time waiting for results, rather than about whether it makes more work

one thing about blowing away a workspace is that the number of files involved is so large that sometimes the behemoth will shut down before the rm -rf job even has a chance to finish. so I usually first rename the workspace to something like trashme, then do rm -rf trashme & and disown %, and then hurry to trigger a new run before the behemoth has a chance to shut down, and then also check back the next day to make sure trashme did in fact entirely disppear

[lrytz]

behemoth will shut down

I sometimes go into the node config and change the Idle delay. It's 5 minutes by default.