Skip to content
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

Named import shadows underscore value import #2212

Closed
olafurpg opened this issue Apr 10, 2017 · 3 comments
Closed

Named import shadows underscore value import #2212

olafurpg opened this issue Apr 10, 2017 · 3 comments

Comments

@olafurpg
Copy link
Contributor

olafurpg commented Apr 10, 2017

I am not sure if this is a bug or intentional behavior. I bumped into this while compiling squants with Dotty.

The following snippet compiles with scalac but not Dotty

package object squants {
  type Time = squants.time.Time
}
package squants.time {
  class Time
  object Time { def x = 2 }
}
package squants.velocity {
  import squants.Time // <-- imports  type alias
  import squants.time._  // <-- imports `Time` value
  object Velocity { Time.x }
}

Dotty reports "E008 member not found":

-- [E008] Member Not Found Error: package.scala --------------------------------
11 |  object Velocity { Time.x }
   |                    ^^^^
   |value `Time` is not a member of squants.type - did you mean `squants.time`?

one error found

It seems that the import on the Time type alias shadows the underscore import on the Time companion object. Commenting out import squants.Time (import on type alias) removes the error.

Commit to reproduce issue in the dotty repo: 2487e78

FWIW, the Dotty behavior feels somewhat more intuitive to me since named imports have a higher precedence.

@smarter
Copy link
Member

smarter commented Apr 10, 2017

This doesn't answer your question, but it seems like the package object for squants should also alias the object, not just the class:

package object squants {
  type Time = squants.time.Time
  val Time = squants.time.Time
}

@propensive
Copy link
Contributor

Regarding the example, I notice that although squants.Time is imported explicitly, it's actually already in the enclosing scope of the squants.velocity package because it's in the squants package object. I'm not sure if that's part of the issue, or if it just means there's a further slight minimization opportunity.

@olafurpg
Copy link
Contributor Author

Here is another example that I'm not sure is related but also involves types and values being imported separately

import scala.math.BigDecimal.RoundingMode
import scala.math.BigDecimal.RoundingMode.RoundingMode

object Money {
  def foo(round: RoundingMode = RoundingMode.HALF_EVEN): Int = ???
}

Dotty reports the following errors

-- [E008] Member Not Found Error: RoundingMode.scala ---------------------------
6 |  def foo(round: RoundingMode = RoundingMode.HALF_EVEN): Int = ???
  |                 ^^^^^^^^^^^^
  |type `RoundingMode` is not a member of math.BigDecimal.type - did you mean `BigDecimal.RoundingMode`?
-- [E008] Member Not Found Error: RoundingMode.scala ---------------------------
6 |  def foo(round: RoundingMode = RoundingMode.HALF_EVEN): Int = ???
  |                                ^^^^^^^^^^^^
  |value `RoundingMode` is not a member of math.BigDecimal.RoundingMode.type - did you mean `RoundingMode.RoundingMode`?

two errors found

while scalac compiles OK.

I can open a separate ticket, but thought I might add it here first to see if it's a duplicate.

olafurpg added a commit to olafurpg/squants that referenced this issue Apr 10, 2017
- Rewrite `apply = parse _` to `apply(x: Any) = parse(x)`
- remove import on type alias that shadowed import on value,
  caused by scala/scala3#2212
olafurpg added a commit to olafurpg/squants that referenced this issue Apr 10, 2017
odersky added a commit to dotty-staging/dotty that referenced this issue Apr 11, 2017
Don't issue an error if when considering a named import that
refers to a valoe or type which does not exist. Instead, disregard
the import an continue.
odersky added a commit that referenced this issue Apr 11, 2017
Fix #2212: Avoid imports in the wrong namespace
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

No branches or pull requests

3 participants