Skip to content

Fix #4342: Adapt outer types when calling into Scala 2 classes #4344

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 14 commits into from

Conversation

gsps
Copy link
Contributor

@gsps gsps commented Apr 19, 2018

See #4342 for some context.

Copy link
Member

@dottybot dottybot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello, and thank you for opening this PR! 🎉

All contributors have signed the CLA, thank you! ❤️

Have an awesome day! ☀️

@gsps gsps requested a review from odersky April 19, 2018 15:47
Copy link
Contributor

@allanrenucci allanrenucci left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you also explain what this does in the commit message

@@ -336,12 +336,23 @@ object ExplicitOuter {
class OuterOps(val ictx: Context) extends AnyVal {
private implicit def ctx: Context = ictx

private def outerType(cls: ClassSymbol): Type = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a comment explaining why this is needed

@gsps
Copy link
Contributor Author

gsps commented Apr 20, 2018

Sure, there you go!

allanrenucci and others added 14 commits April 21, 2018 16:36
We can ignore packages when collecting dependencies for incremental
compilation. We make sure not to ignore dependencies on package object.
1. ApproximatingTypeMap produces Nothing, which is not what is needed.
2. Avoid blind erasure which lose information about the pattern, see tests/patmat/i4314b.scala
Blind substitution of pattern bound type symbol with WildcardType
will cause t2425.scala fail, as the following holds:

    Array[_] <:< Array[Array[_]]

To walkaround the problem, we don't substitute pattern bound symbols
that are immediate parameters to `Array`.
Use TypeBounds instead of WildcardType. WildcardType has the
following unexpected behavior:

    Array[?] <:< Array[Array[?]]
…er, adapt to the old behavior in picking the outer parameter's type, i.e., prefer the enclosing class's self type, rather than the enclosing class itself.
@smarter
Copy link
Member

smarter commented Apr 28, 2018

This PR needs to be rebased to get rid of commits already in master.

Copy link
Contributor

@odersky odersky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for coming to this only now. We have too many open PRs so unless I am assigned I usually don't see what the status is.

The changes to ExplicitOuter look good to me.

@liufengyun @smarter Can you comment on the changes to SpaceEngine and sbt extraction? If they are both good we should merge this now.

@odersky odersky assigned smarter, liufengyun and odersky and unassigned gsps Jan 12, 2019
@smarter
Copy link
Member

smarter commented Jan 12, 2019

I think all these other changes come from commits which are already in master, the PR just needs a rebase.

@smarter smarter removed their assignment Jan 12, 2019
@odersky
Copy link
Contributor

odersky commented Jan 12, 2019

OK @gsps Can you do the rebase then we can get this in quickly.

@smarter
Copy link
Member

smarter commented Jan 26, 2019

Rebased PR opened here: #5801

@smarter smarter closed this Jan 26, 2019
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.

6 participants