-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fix tests on case-insensitive filesystems #4120
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
Fix tests on case-insensitive filesystems #4120
Conversation
} | ||
checkName(claszSymbol) | ||
if (int.symHelper(claszSymbol).isTopLevelModuleClass) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this should be limited to top-level modules, the same problem exists for inner modules no?
7ba1669
to
6e9e68e
Compare
@nicolasstucki Can you fix #4166 as part of this PR? |
6e9e68e
to
7a0cfc7
Compare
#4166 is already fixed by this PR |
20aacf2
to
5a90545
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Good to know about the effectiveName
!
|
||
object Outer { | ||
class X // error | ||
object x |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nicolasstucki Why is this not allowed? It is only an issue when class X
and object x
are top level, right? Scalac does not complain
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those classes will emit Outer$X.class
and Outer$x.class
which may conflict.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so. I think Outer$x$.class
will be emitted. So there is no conflict. I think it is only an issue for top level objects
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the object will generate Outer$x$.class
but is the class needs a companion object it will generate Outer$X$.class
which causes the conflict.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would happen with
object Outer {
case class X()
object x
}
or any other class that generates the module class for it.
No description provided.