Skip to content

Fix #9103: Add additional config to NamedParts accumulator #9106

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

Closed
wants to merge 12 commits into from

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Jun 4, 2020

The NamedParts accumulator always searched the underlying types of TermRef, but this
is the right thing to do only for avoidance. In other situations, notably implicit
scope construction, we should only count the TermRef itself, but not its underlying
type.

odersky added 2 commits June 4, 2020 12:12
The NamedParts accumulator always searched the underlying types of TermRef, but this
is the right thing to do only for avoidance. In other situations, notably implicit
scope construction we should only count the TermRef itself, but not its underlying
type.
widen only if `widenSingletons` is true.
odersky added 3 commits June 4, 2020 16:17
The previous changes failed the community build for squants. What happened was
that an implicit in the package object of squants was not found in motion/AngularAcceleration.

Normally, the context object would be found in the normal implicit context of the use site.
But AngularAcceleration was defined as
```scala
package squants.motion
```
which meant that `squants` by itself was not in the implicit scope. If it had been defined like this:
```scala
package squants
package motion
```
it would have worked fine. So the implicit hit it relied on the fact that under -source:3.0-migration
we also search package prefixes of types. Only, I believe there were no such prefixes normally since the types
in question started with `this[motion]` so no mention of `squants`. But if we widen the term refs on
the paths then we mention something that mentions in turn `scala` and things are OK. I did not track
down what this was, but that's what must have happened.

So, to keep compatibility with old code, we should still enable this under -source:3.0-migration.
Do consider underlying types of singleton types that are not
path prefixes. This is necessary since arguments in apply
prototypes are often singeletons, and in this case we want
to include the implicit scope of their underlying type.
odersky added 2 commits June 6, 2020 18:44
The idea of LazyRefs is that they are always completed in the current context.
But that did not work if the LazyRef is mapped in a type map. Here, the TypeMap's
context was used to do the remap. We now use the context that forced the LazyVal
instead.

The problem manifested itself with failing replTests when the new implicitScope
scheme was used.
odersky added 5 commits June 6, 2020 20:05
In that way, we include all of the implicit scope of Scala 2, except
for package objects. The idea is that everything that is reasonable
should be included in the implicit scope.

Package objects were excluded since they had a dual purpose:

 1. as a way to define implicits that are in scope for a whole project
 2. as a prefix for implicits of all types coming out of that project

It's often that one wants only (1) but then is surprised to also get (2).
@odersky
Copy link
Contributor Author

odersky commented Jun 7, 2020

Dropped in favor of #9119

@odersky odersky closed this Jun 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant