diff options
author | Jason Zaugg <jzaugg@gmail.com> | 2015-09-30 23:46:43 +1000 |
---|---|---|
committer | Jason Zaugg <jzaugg@gmail.com> | 2015-09-30 23:54:21 +1000 |
commit | 5db2d831a79f6ea3edcc305e325be84c21e53c85 (patch) | |
tree | dc4c9c97f96f9ff1788708b67f856e77770ef6c4 /.mailmap | |
parent | 39aa986dfabe4e8d22eb5698b18f773d1a6dfae8 (diff) | |
download | scala-5db2d831a79f6ea3edcc305e325be84c21e53c85.tar.gz scala-5db2d831a79f6ea3edcc305e325be84c21e53c85.tar.bz2 scala-5db2d831a79f6ea3edcc305e325be84c21e53c85.zip |
Improve implicits wildcard imports in the IDE
In 451cab967a, I changed handling of selection of members from
package objects so as to correctly use `somePackage.package.type`
as the prefix, rather than `somePackage`. This fixed generic
substitution for members inherited from superclasses of the
package object.
However, this has subtly changed the scope from which we collect
implicits given a wildcard import. It seems that the IDE gets into
a situation after a scaladoc lookup, which temporarily typechecks
the sources of a package object of a third party library, in which
the members of package object differ from the members of the enclosing
package.
The upshot of this was spurious type errors due to implicit search
discarding an candidate implicit whose symbol is not matched by
typechecking an identifier with the symbol's name at the implicit
usage site (this is how we discard shadowed implicits.)
I'd like to ge to the bottom of this, but in the meantime, I've found
that we can fix the regression by looking up the implicit member
symbols in the package, even while correctly using the package object
as the prefix.
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions