diff options
author | Jason Zaugg <jzaugg@gmail.com> | 2014-03-10 18:20:16 +0100 |
---|---|---|
committer | Jason Zaugg <jzaugg@gmail.com> | 2014-03-10 18:39:50 +0100 |
commit | e6895d7e5f85b56dab986fa0be17ae9edffe288a (patch) | |
tree | 0ee9fcf6f3ff358cba32923932da8e9688ff99a6 /test/files/neg/t8376 | |
parent | 40b7832823d5e1cc39397b8960e62e0283bb0502 (diff) | |
download | scala-e6895d7e5f85b56dab986fa0be17ae9edffe288a.tar.gz scala-e6895d7e5f85b56dab986fa0be17ae9edffe288a.tar.bz2 scala-e6895d7e5f85b56dab986fa0be17ae9edffe288a.zip |
SI-8376 Fix overload resolution with Java varargs
When comparing specificity of two vararg `MethodTypes`, `isAsSpecific`
gets to:
```
case mt @ MethodType(_, _) if bothAreVarargs =>
checkIsApplicable(mt.paramTypes mapConserve repeatedToSingle)
```
The formal parameter type of a Java varargs parameter is represented
as `tq"${defintions.JavaRepeatedParamClass}[$elemTp]"`. For a Scala
repeated parameter, we instead use `defintions.RepeatedParamClass`.
`bothAreVarargs` detects `JavaRepeatedParamClass`, by virtue of:
```
def isRepeatedParamType(tp: Type) = isScalaRepeatedParamType(tp) || isJavaRepeatedParamType(tp)
```
But, `repeatedToSingle` only considers `RepeatedParamClass`.
This bug was ostensibly masked in 2.10.3, but became apparent after
a not-quite-refactoring in 0fe56b9770. It would be good to pin that
change down to a particular line, but I haven't managed that yet.
Diffstat (limited to 'test/files/neg/t8376')
0 files changed, 0 insertions, 0 deletions