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

type alias and object with the same name report bogus error message about companion objects #5031

Closed
scabug opened this issue Sep 27, 2011 · 18 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Sep 27, 2011

Attached is a three-file reproduction with instructions to reproduce with either scalac or sbt.

The bug persists with -no-specialization; and appears in at least 2.8.1 and 2.9.1.

Workaround is to choose a different name for the object.

error: java.lang.NullPointerException
	at scala.tools.nsc.Global$Run.compiles(Global.scala:843)
	at scala.tools.nsc.Global$Run.compiles(Global.scala:844)
	at scala.tools.nsc.Global$Run.compiles(Global.scala:843)
	at scala.tools.nsc.transform.SpecializeTypes.addConcreteSpecMethod(SpecializeTypes.scala:1760)
	at scala.tools.nsc.transform.SpecializeTypes.scala$tools$nsc$transform$SpecializeTypes$$specializeMember(SpecializeTypes.scala:838)
	at scala.tools.nsc.transform.SpecializeTypes$$anonfun$16$$anonfun$apply$17.apply(SpecializeTypes.scala:719)
	at scala.tools.nsc.transform.SpecializeTypes$$anonfun$16$$anonfun$apply$17.apply(SpecializeTypes.scala:718)
	at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:200)
	at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:200)
	at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59)
	at scala.collection.immutable.List.foreach(List.scala:45)
	at scala.collection.TraversableLike$class.flatMap(TraversableLike.scala:200)
	at scala.collection.immutable.List.flatMap(List.scala:45)
	at scala.tools.nsc.transform.SpecializeTypes$$anonfun$16.apply(SpecializeTypes.scala:718)
	at scala.tools.nsc.transform.SpecializeTypes$$anonfun$16.apply(SpecializeTypes.scala:716)
	at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:200)
	at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:200)
	at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59)
@scabug
Copy link
Author

scabug commented Sep 27, 2011

Imported From: https://issues.scala-lang.org/browse/SI-5031?orig=1
Reporter: @retronym
Affected Versions: 2.9.1
Other Milestones: 2.10.0
Attachments:

  • npe.zip (created on Sep 27, 2011 7:33:49 AM UTC, 30773 bytes)

@scabug
Copy link
Author

scabug commented Oct 18, 2011

@okomok said:

Workaround is to choose a different name for the object.

Then, it works well to define a value alias?

package scalaz {
   val Id = Ident
}

@scabug
Copy link
Author

scabug commented Jan 16, 2012

@paulp said:
In 2.10 it says the following:

[error] /repo/scala-issues-dev/tickets/5031/src/main/scala/npe/Id.scala:9: Companions 'type ID' and 'object ID' must be defined in same file:
[error]   Found in /repo/scala-issues-dev/tickets/5031/src/main/scala/npe/package.scala and /repo/scala-issues-dev/tickets/5031/src/main/scala/npe/Id.scala
[error] object ID extends IDs 
[error]        ^

Which sounds like the right error to me, although at a glance the spec doesn't say much about the companionship of type aliases. If I do that, it compiles fine:

package object npe {
	
	type ID = Int
}

package npe {

  trait N[X]

  trait IDs {
  	val id = new N[ID] {}
  }

  object ID extends IDs 
}

Going to call this fixed, reopen if you disagree.

@scabug
Copy link
Author

scabug commented Jan 16, 2012

@retronym said (edited on Jan 16, 2012 12:18:13 PM UTC):
AFAIK, type aliases can't have companions (they are transparent in all other regards, save perhaps type inference), so the error is bogus.

The workaround suggested by Shunsuke Sogame works well enough us, so this isn't pressing. But I'll reopen.

@scabug
Copy link
Author

scabug commented Jan 29, 2012

@paulp said:
Can a type alias and its companion-like term of the same name be defined in separate files?

@scabug
Copy link
Author

scabug commented Jan 30, 2012

@retronym said:
See also #5422 (marked as duplicate), which contains a program that compiled with 2.9.1 that no longer compiles.

@scabug
Copy link
Author

scabug commented Jun 19, 2012

@axel22 said:
I don't know what the verdict here is, and it's not specialization related so I've reassigned.

@scabug
Copy link
Author

scabug commented Jun 19, 2012

@VladUreche said:
Type aliases can't have companion objects.

@scabug
Copy link
Author

scabug commented Jun 19, 2012

@paulp said:
"Type aliases can't have companion objects" unfortunately doesn't clarify much for whomever may attempt this. The precise behavior and relationship of a type alias and a value of the same name, compiled separately or together, is what is at issue, especially if the type alias is defined in a package object. Also at issue is the feasibility of implementation: it is undesirable to have prohibitions which we cannot or will not recognize at compile time and which manifest as mysterious errors.

I know you don't mean "type aliases can't share a name with a term" because that would break the standard library in a hundred places. So I take it you mean "type aliases and terms of the same name have no special relationship."

@scabug
Copy link
Author

scabug commented Jun 19, 2012

@VladUreche said:
Exactly, "type aliases and terms of the same name have no special relationship."

For the implementation feasibility: can you elaborate on that?

@scabug
Copy link
Author

scabug commented Jun 19, 2012

@paulp said:
I admit I don't remember much in the way of details, but because package objects are opened up very early, they tend to offer special challenges. I think the difficulties, should any exist, will make themselves apparent - at which point I will have a better chance of elaborating.

@scabug
Copy link
Author

scabug commented Jul 19, 2012

@Blaisorblade said:
I just ran into this as well when porting my code from 2.9.2 to 2.10.0(-M5), so I realized it's a regression. Is it going to be fixed for 2.10.0? If so, shouldn't this be reprioritized as critical to ensure that it's actually fixed before release? #5031 is currently marked as minor.

I'm currently modifying my source (and others') to workaround this, but I'd like to understand if this is going to be fixed before 2.10 or not - if it's going to be fixed, then I could undo the changes or not push them.

@scabug
Copy link
Author

scabug commented Jul 20, 2012

@hubertp said:
I think a small amount of confusion crept into this bug. Fixed the component and marked as a regression. Hopefully Adriaan is not going to bash me for adding yet another critical bug to the list.

@scabug
Copy link
Author

scabug commented Jul 20, 2012

@Blaisorblade said:
Thanks a lot! I think confusion has arisen because the original bug report was about something else for 2.8.1 and 2.9.1, while Paul Phillips's comment switched the discussion to the regression. It might be worth preserving the original bug report.
But at least, the regression won't be forgot.

@scabug
Copy link
Author

scabug commented Jul 27, 2012

@hubertp said (edited on Jul 27, 2012 8:46:29 AM UTC):
Here is the minimized code from the zip file that illustrates the regression.
Id.scala:

package t5031
object ID

package.scala:

package object t5031 {
  type ID = Int
}

@scabug
Copy link
Author

scabug commented Jul 31, 2012

@hubertp said:
scala/scala#1016

@scabug
Copy link
Author

scabug commented Oct 19, 2012

@jrudolph said:
This is still broken in 2.10.0-RC1 (and a regression from 2.9.2) with separate compilation.

See this case:

https://gist.github.com/3916794

The problem is that the non-companion object can't be accessed at all from code not compiled at the same time as with the type-alias/object code.

The workaround of putting the object into the package object still works.

@scabug
Copy link
Author

scabug commented Oct 29, 2012

@hubertp said:
scala/scala#1532

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants