From bb7e631e23ffd1c678bf41b47d4d52080529ba4a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=A0est=C3=A1k=20V=C3=ADt?= Date: Mon, 12 Dec 2016 11:35:28 +0100 Subject: [PATCH] Fixed a mysterious compile error that appears just in some cases. Before the fix, incremental build sometimes used to pass, but clean builds used to fail all the time. This is the reason why I committed code that was not compilable. --- app/views/libraryIdentification.scala.html | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/app/views/libraryIdentification.scala.html b/app/views/libraryIdentification.scala.html index b9baf0b..3a20e09 100644 --- a/app/views/libraryIdentification.scala.html +++ b/app/views/libraryIdentification.scala.html @@ -1,6 +1,15 @@ @(dep: GroupedDependency, suppressionXmlIdOption: Option[String => String] = None, addLink: Boolean = true, addButtons: Boolean = true) @import com.ysoft.odc.Confidence -@import scala.math.Ordered.orderingToOrdered +@implicitOrdering = @{ + // This implicit should not be theoretically needed, but missing this used to cause somehow non-deterministic scalac behavior: + // The first ….sortBy expression used to pass, while the second one used to fail sometimes. Even though both expressions are essentially the same. + // When these expressions are swapped, still the first (after swapping) one passes and the second one fails, no matter which one is the first and + // which is the second. So, it looks like some compiler bug related to mutable state. + // It also seems to be related to some compiler cache. It is somehow possible to compile it by incremental compilation and some code changes, but + // clean build deterministically fails at the second expression. + // So, making the implicit explicit is a workaround for this issue. + Ordering.Tuple4[Confidence.Value, String, String, String] +} @if(!dep.identifiers.exists(_.confidence >= Confidence.High)){ file: @dep.fileNames.toSeq.sorted.mkString(", ")@if(addButtons){ }