Skip to content

Using java.util.Collections kills the compiler ("class file ... is broken, ...") #536

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.

Sign up for GitHub

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

Jump to bottom
Closed
smarter opened this issue May 5, 2015 · 2 comments
Closed

Using java.util.Collections kills the compiler ("class file ... is broken, ...") #536

smarter opened this issue May 5, 2015 · 2 comments
Labels
prio:low

Comments

@smarter
Copy link
Member

smarter commented May 5, 2015 

object Max {
  java.util.Collections.max(null)
}

Boom:

error: error while loading Collections$1,
 class file /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar(java/util/Collections$1.class) is broken, reading aborted with class java.util.NoSuchElementException
key not found: E
one error found
@retronym
Copy link
Member

retronym commented May 5, 2015

Sounds similar scala/scala#2750, but that symptom appears in other bugs too.

@DarkDimius
Copy link
Contributor

Assigning LowPriority as it does not stop us from bootstrapping.

@odersky odersky mentioned this issue May 7, 2015
Closed
@odersky odersky closed this as completed in 8f020bb May 9, 2015
odersky added a commit to dotty-staging/dotty that referenced this issue Aug 28, 2017
@odersky
Fix scala#536 again
d0b1d74 
Test case was extended and several fixes were necessary to make it pass.
odersky added a commit to dotty-staging/dotty that referenced this issue Aug 29, 2017
@odersky
Fix scala#536 again
706afab 
Test case was extended and several fixes were necessary to make it pass.
odersky added a commit to dotty-staging/dotty that referenced this issue Aug 31, 2017
@odersky
Fix scala#536 again
a3f1f32 
Test case was extended and several fixes were necessary to make it pass.
odersky added a commit to dotty-staging/dotty that referenced this issue Aug 31, 2017
@odersky
Fix scala#536 again
ac40844 
Test case was extended and several fixes were necessary to make it pass.
odersky added a commit that referenced this issue Aug 31, 2017
@odersky
Fix #536 again
23a16fe 
Test case was extended and several fixes were necessary to make it pass.
odersky added a commit to dotty-staging/dotty that referenced this issue Sep 4, 2017
@odersky
Fix scala#536 again
0edead7 
Test case was extended and several fixes were necessary to make it pass.
liufengyun pushed a commit to dotty-staging/dotty that referenced this issue Sep 6, 2017
@odersky @liufengyun
Fix scala#536 again
ac393fc 
Test case was extended and several fixes were necessary to make it pass.
odersky added a commit to dotty-staging/dotty that referenced this issue Sep 6, 2017
@odersky
Fix scala#536 again
6cd44c8 
Test case was extended and several fixes were necessary to make it pass.
odersky added a commit to dotty-staging/dotty that referenced this issue Sep 8, 2017
@odersky
Fix scala#536 again
82489ed 
Test case was extended and several fixes were necessary to make it pass.
odersky added a commit to dotty-staging/dotty that referenced this issue Sep 14, 2017
@odersky
Fix scala#536 again
71f1bfa 
Test case was extended and several fixes were necessary to make it pass.
odersky added a commit to dotty-staging/dotty that referenced this issue Sep 17, 2017
@odersky
Fix scala#536 again
3489967 
Test case was extended and several fixes were necessary to make it pass.
odersky added a commit to dotty-staging/dotty that referenced this issue Sep 20, 2017
@odersky
Fix scala#536 again
357e2ae 
Test case was extended and several fixes were necessary to make it pass.
odersky added a commit to dotty-staging/dotty that referenced this issue Aug 29, 2019
@odersky
Reclassify test
1d48a93 
i536.scala previously compiled since the type argument was inferred to be Nothing.
But that inference is useless; it just hides a runtime failure. The issue scala#536
only complained that the compiler crashed, so having a negative outcome
is permissible.
odersky added a commit to dotty-staging/dotty that referenced this issue Aug 29, 2019
@odersky
Reclassify test
7829682 
i536.scala previously compiled since the type argument was inferred to be Nothing.
But that inference is useless; it just hides a runtime failure. The issue scala#536
only complained that the compiler crashed, so having a negative outcome
is permissible.
odersky added a commit to dotty-staging/dotty that referenced this issue Aug 29, 2019
@odersky
Don't interpolate downwards to a bottom type
a095a4b 
If the result of a covariant type variable interpolation would be a bottom type,
wait instead. This could make the variable be inferred to its upper bound after all,
if we do not need a fully instantiated type right away.

This makes a difference for indentation whereever we have a situation like this:
```
  def foo: T =
    bla.asInstanceOf
```
With indentation on, this is now equivalent to
```
  def foo: T = {
    bla.asInstanceof
  }
```
This means there is now an added opportunity for an interpolation step, of
the asInstanceOf, which would go downwards to Nothing. So indentation changes
the inferred type, which is very bad. With the commit the problem is
avoided.

Two tests are reclassified:

i536.scala previously compiled since the type argument was inferred to be Nothing.
But that inference is useless; it just hides a runtime failure. The issue scala#536
only complained that the compiler crashed, so having a negative outcome
is permissible.

enum-interop is similar except that the example makes even less sense and compiles only
because Nothing was inferred by accedient.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
prio:low
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix/#536 nested classes dotty-staging/dotty
3 participants
@smarter @retronym @DarkDimius