-
-
Notifications
You must be signed in to change notification settings - Fork 364
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
Fix issue #2958 - deduplicate (anonymous) tasks in result #2959
Conversation
Ensure when flatMap-ing, that we don't append duplicates. Whether this is correct needs yet to be analyzed, but in general, we don't enfore unique-ness of task results, and even when we evaluate disjuct tasks, we can't assume that all results are disjuct, hence using a strict Agg, which enforces uniqueness on append seems not correct. Here's my reasoning: If we have two tasks A and B, and B just forwards the result of A as it's own result, both tasks return the same result.
Strict.Agg.from( | ||
Loose.Agg.from( | ||
finishedOptsMap.values.flatMap(_.toSeq.flatMap(_.newEvaluated)) | ||
) | ||
), | ||
transitive, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So as far as I can tell, evaluated: Agg[Task[_]]
is only used in the test suite, and transitive: Agg[Task[_]]
is not used at all. So this should be fine from a runtime behavior perspective. And anyway it's private[mill]
so we change things without worrying about compatibility.
As for what the correct thing to do here is, Strict.Agg.from(Loose.Agg.from(can just be a single
.distinct` call I think. Then maybe just a comment and a simple test case illustrating the edge case and then we should be good to go
My new test fails on Windows, but I have no idea why.
|
@lefou is it because your target starts with the word |
Thanks for the hint. In fact, it's the exact name "com1" that is reserved, although I wonder why the file name extension isn't counted as part of the name. There are other reserved names, which we should try to detect and handle somehow in Mill, to avoid misleading error messages: |
Anonymous tasks can be defined as
val
ordef
. This is in contrast to named targets, which always need to be defined asdef
.Also, anonymous tasks end up in the terminal group of the target that's using them.
If the same anonymous task is used in multiple targets, it also ends up multiple time in the task results. When a
Evaluator.Results
is created, this clashes, due to the use of aStrict.Agg
forEvalutor.Results.evaluated
.This change deduplicated the results before constructing the
Evaluator.Results
.Fix: #2958