Make all numeric coercions explicit.

Optimistically, this is preparation for a day when we don't
let numeric types drift with the winds. Even without the optimism
it's a good idea. It flushed out an undocumented change in
the math package object relative to the methods being forwarded (a
type is widened from what is returned in java) so I documented
the intentionality of it.

Managing type coercions manually is a bit tedious, no doubt,
but it's not tedious enough to warrant abandoning type safety
just because java did it.

1 files changed, 2 insertions, 2 deletions

diff --git a/src/scaladoc/scala/tools/nsc/doc/html/SyntaxHigh.scala b/src/scaladoc/scala/tools/nsc/doc/html/SyntaxHigh.scala
index fe0fc64033..910148532d 100644
--- a/src/scaladoc/scala/tools/nsc/doc/html/SyntaxHigh.scala
+++ b/src/scaladoc/scala/tools/nsc/doc/html/SyntaxHigh.scala
@@ -260,8 +260,8 @@ private[html] object SyntaxHigh {
             parse(buf(i).toChar.toString, i+1)
         case _ =>
           if (i == 0 || (i >= 1 && !Character.isJavaIdentifierPart(buf(i-1).toChar))) {
-            if (Character.isDigit(buf(i)) ||
-                (buf(i) == '.' && i + 1 < buf.length && Character.isDigit(buf(i+1)))) {
+            if (Character.isDigit(buf(i).toInt) ||
+                (buf(i) == '.' && i + 1 < buf.length && Character.isDigit(buf(i+1).toInt))) {
               val s = numlit(i)
               parse("<span class=\"num\">"+s+"</span>", i+s.length)
             } else {